Game.Development.and.Production.Fly.[6.36 MB_www.netz.ru]

TE AM FL Y Game Development and Production Erik Bethke Wordware Publishing, Inc. Library of Congress Cataloging-in-Publication Data Bethke, Erik. Game development and production / by Erik Bethke. p. cm. ISBN 1-55622-951-8 1. Computer games--Design. 2. Computer games--Programming. 3. Project management. I. Title. QA76.76.C672 B47 2002 794.8'1526--dc21 2002153470 CIP © 2003, Wordware Publishing, Inc. All Rights Reserved 2320 Los Rios Boulevard Plano, Texas 75074 No part of this book may be reproduced in any form or by any means without permission in writing from Wordware Publishing, Inc. Printed in the United States of America ISBN 1-55622-951-8 10 9 8 7 6 5 4 3 2 1 0301 Product names mentioned are used for identification purposes only and may be trademarks of their respective companies. All inquiries for volume purchases of this book should be addressed to Wordware Publishing, Inc., at the above address. Telephone inquiries may be made by calling: (972) 423-0090 Contents Foreword . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . xxi Part I—Introduction to Game Development Chapter 1 What Does This Book Cover? . . How to Make a Game. . . . . . . . . . . . . . . First Have a Plan . . . . . . . . . . . . . . . . . Organize Your Team Effectively . . . . . . . . . Game Development Is Software Development . Where to Turn for Outside Help . . . . . . . . . How to Ship a Game . . . . . . . . . . . . . . . Post-Release . . . . . . . . . . . . . . . . . . . Success and the Long Race . . . . . . . . . . . How to Use This Book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3 3 4 4 4 5 5 5 6 Chapter 2 Why Make Games? . . . . . . . . . . . . . . . . . . 7 To Share a Dream . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Games Teach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Game Genres Satisfy Different Appetites . . . . . . . . . . . . . . 8 Gambling, Puzzle, and Parlor Games. . . . . . . . . . . . . . . . 8 Military and Sports Simulations. . . . . . . . . . . . . . . . . . 10 Role-Playing Games . . . . . . . . . . . . . . . . . . . . . . . . 12 Youth Making Games . . . . . . . . . . . . . . . . . . . . . . . . . 13 On Money . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Why Make Games? . . . . . . . . . . . . . . . . . . . . . . . . . . 14 What Makes Game Development Hard? . . . . . The Importance of Planning . . . . . . . . . . . . . . . . . . . . Very Few Titles Are Profitable . . . . . . . . . . . . . . . . . . . 500,000 Units to Break Even? . . . . . . . . . . . . . . . . . Employee Compensation and Royalties . . . . . . . . . . . . What Are the Financial Expectations for Your Game? . . . . . . The Scope of the Game Must Match Financial Parameters . . Why Your Game Should Profit . . . . . . . . . . . . . . . . . . . Feature Storm . . . . . . . . . . . . . . . . . . . . . . . . . . If the Game Is Worth Making, Make It Excellent . . . . . . . . . . . . . . . . . 15 15 15 16 17 17 17 18 18 19 iii Chapter 3 iv Contents Excellence in Spades . . . . . . . . . . . . . . . . . . . . . . . Game Making Is a Long Race of Many Game Projects . . . . . A Brief History of Software Development. . . . . . . . . . . . Overly Long Game Projects Are Disastrous . . . . . . . . . . What Late Games Do to the Publisher . . . . . . . . . . . . Our Project Plan Behind Starfleet Command . . . . . . . . . . The Vision for Starfleet Command . . . . . . . . . . . . . . Constraints Give Much Needed Focus. . . . . . . . . . . . . . On Bugs Shipped in Starfleet Command. . . . . . . . . . . . . Well-Met Goals Enable Future Successes . . . . . . . . . . . . Strong Game Developers Have Strong Foundations . . . . . . The Tension between Preproduction and Production. . . . . . The Power of the Console . . . . . . . . . . . . . . . . . . . . Why Aren’t All Publishers Using Preproduction?. . . . . . . . The Process Is Changing . . . . . . . . . . . . . . . . . . . A Strong Plan Makes Game Development Easy . . . . . . . . The Gravitational Pull of Feature Creep . . . . . . . . . . . . . Task Visibility for Team Motivation and for Progress Tracking Use Your Core Competencies and Outsource the Rest . . . . . A Pitfall of Success—Fan-Requested Features and Changes. . The Relentless Pace of Technology . . . . . . . . . . . . . . . The Art of War and Games . . . . . . . . . . . . . . . . . . . . Chapter 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 20 21 21 22 22 23 24 24 25 25 25 26 27 27 28 28 29 29 29 30 32 33 33 33 33 34 35 35 35 36 Game Project Survival Test . . The Game Project Survival Test . . . . . . . Game Requirements . . . . . . . . . . . . Planning. . . . . . . . . . . . . . . . . . . Project Control . . . . . . . . . . . . . . . Risk Management . . . . . . . . . . . . . Personnel . . . . . . . . . . . . . . . . . . Calculating Your Project’s Score . . . . . What Does My Score Mean? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Part II—How to Make a Game Chapter 5 What Is a Game Made Of? . . . . . . . . . . . . . The Extended Development Team. . . . . . . . . . . . . . . . . Game Production Parts . . . . . . . . . . . . . . . . . . . . . . . Design Parts . . . . . . . . . . . . . . . . . . . . . . . . . . . Where Do Lead Designers Come From? . . . . . . . . . . How Do You Nail Down the Game Mechanics? . . . . . . . Who Are the Level and Mission Designers?. . . . . . . . . Story and Dialogue Writers Are Writers for Interactivity. . Coding Parts . . . . . . . . . . . . . . . . . . . . . . . . . . . Lead Programmers and Technical Directors. . . . . . . . . Game Mechanics Programmer . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 39 39 39 40 40 40 41 41 42 43 Contents v 3D Graphics Programmer . . . . . . . . Artificial Intelligence Programmer . . . . User Interface Programmer . . . . . . . Audio Programmer . . . . . . . . . . . . Tools Programmer . . . . . . . . . . . . Mission/Level Editor Programmer. . . . Network, Server, or Client Programmer? Art Parts . . . . . . . . . . . . . . . . . . . Art Director . . . . . . . . . . . . . . . . Concept Artist . . . . . . . . . . . . . . . 2D Artist/Interface Designer . . . . . . . 3D Modeler . . . . . . . . . . . . . . . . Character Modeler . . . . . . . . . . . . Texture Artist . . . . . . . . . . . . . . . Animator/Motion Capture Studio . . . . Storyboarder. . . . . . . . . . . . . . . . Audio Parts . . . . . . . . . . . . . . . . . . Voice-Overs . . . . . . . . . . . . . . . . Sound Effects . . . . . . . . . . . . . . . Music . . . . . . . . . . . . . . . . . . . Management Parts . . . . . . . . . . . . . . Line Producer . . . . . . . . . . . . . . . Associate Producer . . . . . . . . . . . . Studio Head/Executive Producer. . . . . Producer . . . . . . . . . . . . . . . . . . Quality Assurance Parts . . . . . . . . . . . . Publisher QA Parts. . . . . . . . . . . . . . QA Lead . . . . . . . . . . . . . . . . . . Main Team . . . . . . . . . . . . . . . . . Multiplayer Team . . . . . . . . . . . . . Fresh Teams . . . . . . . . . . . . . . . . Compatibility Team . . . . . . . . . . . . Localization Team . . . . . . . . . . . . . Beta Testing . . . . . . . . . . . . . . . . . Beta Testers . . . . . . . . . . . . . . . . Beta Testing Program Manager . . . . . Business Parts. . . . . . . . . . . . . . . . . . Business Development Parts . . . . . . . . Business Development Executive . . . . Publisher CEO and President . . . . . . Studio Heads . . . . . . . . . . . . . . . Lawyers . . . . . . . . . . . . . . . . . . Licensing Parts . . . . . . . . . . . . . . . . Promoting, Buying, and Selling Parts. . . . Sales Executive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 43 44 44 44 44 45 45 46 46 47 47 47 48 48 49 49 49 49 50 50 50 50 51 51 52 52 52 53 53 53 53 53 54 54 54 55 55 55 55 55 55 56 56 56 vi Contents Sales Force and Retail Purchasing Agents . Press Relations Manager . . . . . . . . . . Trade Shows . . . . . . . . . . . . . . . . . Other Trade Shows and Events . . . . . . The Marketing of a Game. . . . . . . . . . Hardcore Fans . . . . . . . . . . . . . . . . Manuals and Strategy Guides . . . . . . . . . Manual . . . . . . . . . . . . . . . . . . . . Strategy Guide . . . . . . . . . . . . . . . Manufacturing Parts . . . . . . . . . . . . . . Hardware Manufacturer Parts. . . . . . . . . Console Manufacturers . . . . . . . . . . . Hardware Representatives . . . . . . . . . Post-Release Parts . . . . . . . . . . . . . . . . Chapter 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 57 57 58 59 59 60 60 60 61 61 61 61 62 65 65 66 67 70 70 70 72 73 74 Business Context First . . . . The Project Triangle . . . . . . . . . . . . . Implications of the Project Triangle. . . . Various Games and the Project Triangle . Questions for You to Answer . . . . . . . . . What to Do with These Answers . . . . . An Ultra-Low Budget Game . . . . . . Fixed Budget, Fixed Deadline . . . . . High-Profile/High-Quality Projects . . Walk Away . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapter 7 Key Design Elements . . . . . . . . . . . . . . . Business Context Shapes Design, or Does Design Shape the Business Context? . . . . . . . . . . . . . . . . . . . . . . . Reconcile the Business Context and Game Idea Early . . . . . . The Effects of a Slipped Game . . . . . . . . . . . . . . . . Methods and the Unified Development Process . . . . . . . . . What Is a Development Method? . . . . . . . . . . . . . . . . Why Use the Unified Software Development Process? . . . . Requirements Capture . . . . . . . . . . . . . . . . . . . . . . Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . Case Studies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Case Study I—Diablo . . . . . . . . . . . . . . . . . . . . . . Use Cases of Diablo . . . . . . . . . . . . . . . . . . . . . . Quick Analysis of the Use Cases of Diablo . . . . . . . . . Case Study II—Gran Turismo . . . . . . . . . . . . . . . . . . Use Cases of Gran Turismo. . . . . . . . . . . . . . . . . . Quick Analysis of the Use Cases of Gran Turismo . . . . . The Key Design Elements of Your Game . . . . . . . . . . . The Battle of the Counterterrorists Games . . . . . . . . . . The Key Design Elements of Rainbow Six . . . . . . . . . . 75 . . . . . . . . . . . . . . . . . . 76 76 77 81 81 81 82 82 87 87 88 89 90 92 93 94 94 95 Contents vii Are We Playing a Mission or Planning a Mission?. . . . . . . 95 The Key Design Elements of Counter-Strike . . . . . . . . . 96 Most Popular Multiplayer Game . . . . . . . . . . . . . . . . 96 Of Intersecting Sets and Elite Forces . . . . . . . . . . . . . 97 Some Straight Questions to Ask Yourself . . . . . . . . . . . . . . 99 What Genre or Genres Does Your Game Feature? . . . . . . 99 Will the Game Be Single-Player, Multiplayer, or Both? . . . . 99 What Is the Platform?. . . . . . . . . . . . . . . . . . . . . . 99 What Is Your Target Market? . . . . . . . . . . . . . . . . . 100 What Major Technologies Are You Using? . . . . . . . . . . 100 Now What? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 Chapter 8 Game Design Document . . . . . . . . . . . . . . What Is a Game Design Document and What Does It Do? . . . . What About the Proposal Document? . . . . . . . . . . . . . . . When Do You Write the Game Design Document? . . . . . . . . What Should Go into a Game Design Document? . . . . . . . . . Section One: Defining the Game . . . . . . . . . . . . . . . . Articulate What the Game Is as Clearly as Possible . . . . . Set the Mood . . . . . . . . . . . . . . . . . . . . . . . . . . Section Two: Core Gameplay . . . . . . . . . . . . . . . . . . The Main Game View . . . . . . . . . . . . . . . . . . . . . Core Player Activity . . . . . . . . . . . . . . . . . . . . . . The Controller Diagram . . . . . . . . . . . . . . . . . . . . In-Game User Interface . . . . . . . . . . . . . . . . . . . . Section Three: Contextual Gameplay . . . . . . . . . . . . . . Shell Menus . . . . . . . . . . . . . . . . . . . . . . . . . . The Nuts and Bolts of Game Mechanics . . . . . . . . . . . Tutorial Mechanics. . . . . . . . . . . . . . . . . . . . . . . Multiplayer Mechanics . . . . . . . . . . . . . . . . . . . . Section Four: Talk Story . . . . . . . . . . . . . . . . . . . . . World Backstory . . . . . . . . . . . . . . . . . . . . . . . . Character Backgrounds . . . . . . . . . . . . . . . . . . . . Level, Mission, and Area Design . . . . . . . . . . . . . . . Cut Scene Descriptions . . . . . . . . . . . . . . . . . . . . Section Five: Cover Your Assets . . . . . . . . . . . . . . . . 2D Sprites or 3D Models . . . . . . . . . . . . . . . . . . . Missions, Levels, or Areas . . . . . . . . . . . . . . . . . . Voice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Key Framing and Motion Capture . . . . . . . . . . . . . . Sound Effects . . . . . . . . . . . . . . . . . . . . . . . . . Music . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Special Effects . . . . . . . . . . . . . . . . . . . . . . . . . Stepping Back a Bit . . . . . . . . . . . . . . . . . . . . . . . . . 101 101 102 103 105 106 106 107 107 108 108 108 108 109 109 109 109 110 111 112 112 113 114 115 115 115 116 117 121 121 125 127 viii Contents Chapter 9 The Technical Design Document . . . . . . . . . Object-Oriented Design . . . . . . . . . . . . . . . . . . . . . . . Purpose of the Technical Design Document . . . . . . . . . . . . Why Have a Software Development Process? . . . . . . . . . The Unified Software Development Process . . . . . . . . . . Core Workflows of the Unified Process. . . . . . . . . . . . Phases of a Workflow in the Unified Process. . . . . . . . . When Should the Technical Design Document Be Written? . . What Goes into the Technical Design Document?. . . . . . . . . Requirements Capture . . . . . . . . . . . . . . . . . . . . . . Reverse Engineering . . . . . . . . . . . . . . . . . . . . . Nonobvious Requirements . . . . . . . . . . . . . . . . . . Requirements Analysis . . . . . . . . . . . . . . . . . . . . . . Class Diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . Relationships . . . . . . . . . . . . . . . . . . . . . . . . . . Drawing “is a” and “has a” Relationships and Ordinalities . . . . . . . . . . . . . . . . . . . . . . . . . . . Adding Annotation . . . . . . . . . . . . . . . . . . . . . . . Other UML Diagram Types . . . . . . . . . . . . . . . . . . . Dynamic Modeling . . . . . . . . . . . . . . . . . . . . . . . Architectural Diagrams . . . . . . . . . . . . . . . . . . . . Large-Scale Planning and the Evil of a Long Build Time . . . Refactoring . . . . . . . . . . . . . . . . . . . . . . . . . . . Insulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . Forward and Backward Code Generation with a Modeling Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . Testing Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . Unit Testing and White Box Testing . . . . . . . . . . . . . Black Box Testing . . . . . . . . . . . . . . . . . . . . . . . Beta Testing . . . . . . . . . . . . . . . . . . . . . . . . . . From Use Cases to Test Cases . . . . . . . . . . . . . . . . The Project Plan. . . . . . . . . . . . . . . . . . . What Is the Project Plan? . . . . . . . . . . . . . . . . . . . . . . How Do We Create the Project Plan? . . . . . . . . . . . . . . . Gantt and PERT Charts for Organizing Project Tasks . . . . . Focusing on the Gantt Chart . . . . . . . . . . . . . . . . . Using the Technical Design Document . . . . . . . . . . . . Task Granularity and Task Leveling . . . . . . . . . . . . . How Long Will That Task Take? . . . . . . . . . . . . . . . Short Time Estimate Possibilities . . . . . . . . . . . . . . Estimating Research Tasks . . . . . . . . . . . . . . . . . . Task Prioritization . . . . . . . . . . . . . . . . . . . . . . . Resource Leveling . . . . . . . . . . . . . . . . . . . . . . . Task Dependencies . . . . . . . . . . . . . . . . . . . . . . 129 129 130 132 133 134 134 135 136 136 143 143 144 145 146 146 147 147 148 149 150 150 151 154 154 154 155 155 155 157 157 157 158 160 161 163 163 165 165 166 171 172 Chapter 10 Contents ix The Top Ten Risks Document . . . . . . . . . . . . . . . . . . 174 The Non-Zero Chance of Delivery . . . . . . . . . . . . . . . . . 175 Chapter 11 Task Tracking . . . . . . . . . . Production Begins—Now What? . . . . . . . Task Visibility . . . . . . . . . . . . . . . . . The Wall . . . . . . . . . . . . . . . . . . . . Journals . . . . . . . . . . . . . . . . . . . . . The Cult of the Yellow Notebook . . . . . Walk Around . . . . . . . . . . . . . . . . . . Milestone Orientation Meetings . . . . . . . Praise People Publicly . . . . . . . . . . . Maintain the Gantt Chart . . . . . . . . . . . Update the Risks Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 177 177 177 179 179 180 180 180 181 182 183 183 184 185 185 186 186 187 187 188 188 188 189 190 190 191 191 191 192 192 192 192 193 193 194 195 195 195 196 196 Chapter 12 Outsourcing Strategies. . . . . . . . . . . . . . . Why Outsource? . . . . . . . . . . . . . . . . . . . . . . . . . . . When to Think About Outsourcing . . . . . . . . . . . . . . . . . What to Outsource . . . . . . . . . . . . . . . . . . . . . . . . . . Do Not Outsource Programming—Exceptions Noted . . . . . On Outsourcing Art. . . . . . . . . . . . . . . . . . . . . . . . Movies, Cut Scenes, or Full Motion Video . . . . . . . . . . 3D Models—Modeling. . . . . . . . . . . . . . . . . . . . . Animation and Motion Capture . . . . . . . . . . . . . . . . User Interface Art . . . . . . . . . . . . . . . . . . . . . . . Audio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Music . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sound Effects . . . . . . . . . . . . . . . . . . . . . . . . . Voice-Over . . . . . . . . . . . . . . . . . . . . . . . . . . . What Else to Outsource . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapter 13 Shipping Your Game . Shipping Is a Phase . . . . . . . . How Do You Ship a Great Game? . Alpha—Feature Complete . . . . . What Is Feature Complete? . . Additional Content . . . . . . Feature Trimming . . . . . . Testing Plan . . . . . . . . . . . . Publisher QA . . . . . . . . . . Team Testing . . . . . . . . . . Project Leader Testing . . . . . Automated Testing . . . . . . . Focus Group Testing . . . . . . Beta Testing. . . . . . . . . . . Open or Closed Beta Test? . x Contents Manufacturer Testing. . . . . . . Licensor Testing . . . . . . . . . How Do You Balance a Game? . . Final Candidate Cycle . . . . . . . . Transition, Ship, and Point Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 198 198 200 200 Part III—Game Development Chapter 14 Chapter 15 Requirements Gathering . . . The Flavors of Requirements . . . . . . Creative/License Requirements . . . Technical Requirements . . . . . . . . Fiscal and Temporal Requirements . . Use Case Diagrams . . . . . . . . . . . . AM FL Y . . . . . . . . . . . . . . . . . . The Vision Document . . . . . . . Write the Vision Document Twice . . . . . . So Is the Vision Document a Proposal? . . . Only 1 Percent Catch the Eye . . . . . . . . What About the Precious Game Secrets? Visuals . . . . . . . . . . . . . . . . . . . Tactile . . . . . . . . . . . . . . . . . . . What About the Words? . . . . . . . . . . Contact Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 205 206 206 207 207 208 208 209 211 211 211 212 213 213 215 215 216 216 216 217 218 218 219 220 221 222 222 223 223 224 224 224 225 225 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapter 16 The Design Document . . . . . . . . . . . . . . . What Does the Game Design Document Do? . . . . . . . . . . . The Game Design Document as a Process. . . . . . . . . . . . . Game Concept . . . . . . . . . . . . . . . . . . . . . . . . . . Brainstorm . . . . . . . . . . . . . . . . . . . . . . . . . . . Delegate Design . . . . . . . . . . . . . . . . . . . . . . . . Managing the Design Document . . . . . . . . . . . . . . . 60 Seconds of Gameplay. . . . . . . . . . . . . . . . . . . . Core Gameplay. . . . . . . . . . . . . . . . . . . . . . . . . The Walkthrough . . . . . . . . . . . . . . . . . . . . . . . Asset Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . Use of Other Games . . . . . . . . . . . . . . . . . . . . . . Menu Design . . . . . . . . . . . . . . . . . . . . . . . . . . Game Mechanics Detail . . . . . . . . . . . . . . . . . . . . Write the Manual? . . . . . . . . . . . . . . . . . . . . . . . Concept Sketches and Art Style Guide . . . . . . . . . . . . On Completeness and Uncertainty . . . . . . . . . . . . . . Cut Features Even Before Considering the Schedule . . . . . Maintain the Game Design Document . . . . . . . . . . . . . On Fulfilled Expectations . . . . . . . . . . . . . . . . . . . . . . TE Team-Fly® Contents xi Chapter 17 Unified Modeling Language Survival Guide . . . Use Cases Deliver Requirements. . . . . . . . . . . . . . . . . . Class Diagrams Are the Keystone of Design. . . . . . . . . . . . Detailed Syntax of the Class Diagram . . . . . . . . . . . . . . . Associations . . . . . . . . . . . . . . . . . . . . . . . . . . . . Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Operations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . Forward and Reverse Engineering of the Class Diagram . . . . . The Other Seven Diagrams of UML . . . . . . . . . . . . . . . . Static Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . Dynamic Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 227 228 230 231 232 232 233 238 238 240 245 245 247 247 247 247 249 250 251 252 252 252 253 253 254 254 255 255 256 256 257 259 260 260 261 261 261 262 264 264 264 Chapter 18 Technical Design . . . . . . . . . . . . . Nominate Functional Leads . . . . . . . . . . . . . . . Synthesize Use Cases and Nonvisible Requirements . Start with the Use Cases . . . . . . . . . . . . . . . Casual, Frequent Design Review . . . . . . . . . Nonvisible Requirements . . . . . . . . . . . . . . Measure Twice, Cut Once . . . . . . . . . . . . . . Specify Tools, Languages, and Processes . . . . . . Goals for the Architecture . . . . . . . . . . . . . . Identify Areas of Likely Change . . . . . . . . . . . The Quality Assurance Plan. . . . . . . . . . . . . . . Defect Tracking . . . . . . . . . . . . . . . . . . . . Defect Tracking Software . . . . . . . . . . . . . The Testing Plan . . . . . . . . . . . . . . . . . . . How Many Bugs Are Left to Find? . . . . . . . . Defect Pooling . . . . . . . . . . . . . . . . . . . Defect Seeding . . . . . . . . . . . . . . . . . . . Political Resistance . . . . . . . . . . . . . . . . Automated Testing. . . . . . . . . . . . . . . . . Beta Testing . . . . . . . . . . . . . . . . . . . . When to Release the Game . . . . . . . . . . . . Time Estimates . . . . . . . . . Two Ways to Estimate a Task . . . . . . . . . Time Boxing . . . . . . . . . . . . . . . . Task Estimating. . . . . . . . . . . . . . . Art . . . . . . . . . . . . . . . . . . . . Design . . . . . . . . . . . . . . . . . . Programming. . . . . . . . . . . . . . . Each Shall Estimate Thy Own Tasks . . . Save Your Plans and Compare . . . . . . . Making the Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapter 19 xii Contents Chapter 20 Putting It All Together into a Plan . . . . . . . . . Let’s Create a Schedule for FishFood! . . . . . . . . . . . . . . . Create a New Project File . . . . . . . . . . . . . . . . . . . . What Is a PERT/Gantt Chart Anyway? . . . . . . . . . . . . . Start Entering Tasks . . . . . . . . . . . . . . . . . . . . . . . Tasks Are Performed by Resources . . . . . . . . . . . . . . . Where Does All of This Task Information Come From? . . . . Organizing Tasks . . . . . . . . . . . . . . . . . . . . . . . . . Task Granularity . . . . . . . . . . . . . . . . . . . . . . . . . How to Account for Vacation and Sick Time . . . . . . . . . . Remember Odd Tasks . . . . . . . . . . . . . . . . . . . . . . Time Leveling in Project . . . . . . . . . . . . . . . . . . . . . Let it Jell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . How to Distribute the Schedule to the Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265 266 266 266 268 269 269 270 270 271 271 271 273 273 275 275 275 277 278 279 279 282 285 286 287 287 288 288 288 289 290 290 293 293 294 294 295 299 299 301 302 302 303 Chapter 21 Measuring Progress . . . . . . On Leadership . . . . . . . . . . . . . . . . . Know What Your Goal Is at All Times . . . Set Goals, Not Hours . . . . . . . . . . . . Task Tracking . . . . . . . . . . . . . . . . . Only Visible Tasks Are Completed . . . . The Daily Journal . . . . . . . . . . . . The Wall . . . . . . . . . . . . . . . . . Team Meetings . . . . . . . . . . . . . . . Of Leaves and Gutters . . . . . . . . . . . Controlling Feature Creep . . . Great Games Satisfy Player Expectations . . Feature Creep Occurs During Design . . . Primary, Secondary, and Tertiary . . . . . Feature Walking. . . . . . . . . . . . . . . Publisher-Suggested Features . . . . . . . Push Independent Tasks to the End . . . . Regularly Practice Feature Cutting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapter 22 Chapter 23 Alpha, Beta, Go Final! The Test of Well-Laid Plans . . . . On Alpha. . . . . . . . . . . . . On to Beta . . . . . . . . . . . . The Finale . . . . . . . . . . . . Chapter 24 Point Releases vs. Patches . . . . . . . . . . . . Software Complexity and the Fragility of Computers . . . . . How About Those Console Games—They Don’t Patch!? . . . Online Games—the Perpetual Beta? . . . . . . . . . . . . . . Point Release as a Sugarcoated Term for Patch. . . . . . . . . Fan Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . Contents xiii The Publisher-Developer Post-Release Relationship . . . . . . . 303 Tools for Creating Patches . . . . . . . . . . . . . . . . . . . . . 304 User Extensibility—The Magical Patch . . . . . . . . . . . . . . 305 Chapter 25 Garage Development Spans the Internet . . . . . 307 Silver Creek Entertainment. . . . . . . . . . . . . . . . . . . . . 307 Part IV—Game Development Resource Guide Chapter 26 Getting a Job in the Game Industry . . . . . . . . Who Is Trying to Get into Games? . . . . . . . . . . . . . . . . . You Want Me to Do What? Oh, I Would Rather Do This . . . . . Hours of the Game Industry . . . . . . . . . . . . . . . . . . . . You Did Not Scare Me—I Love Games AND I Want In! . . . . . How to Get a Job as a Programmer . . . . . . . . . . . . . . . . . Artists and Their Portfolios . . . . . . . . . . . . . . . . . . . . . How Do I Become a Tester? . . . . . . . . . . . . . . . . . . . . I Have a Great Idea for a Game—I Want to Be a Designer!. . . . So You Want to Be a Producer . . . . . . . . . . . . . . . . . . . Go to GDC—Free! . . . . . . . . . . . . . . . . . . . . . . . . . . What About Those Recruiters? . . . . . . . . . . . . . . . . . . . Resumes, Demo Reels, and the Interview . . . . . . . . . . . . . Honesty vs. Modesty . . . . . . . . . . . . . . . . . . . . . . . 313 313 314 314 315 316 317 318 318 318 319 320 320 320 323 324 324 325 326 328 329 329 330 331 331 332 332 332 332 334 335 335 335 335 335 336 336 Chapter 27 Starting a Game Development Company . . . . . Find a Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I Have a Plan; Now How Do I Get Started? . . . . . . . . . . . . Rounding Out Your Development Team . . . . . . . . . . . . . . Where to Locate Your Game Company . . . . . . . . . . . . . . . Lawyer and Accountant . . . . . . . . . . . . . . . . . . . . . . . Deciding on the Type of Company . . . . . . . . . . . . . . . . . Non-Corporation . . . . . . . . . . . . . . . . . . . . . . . . . Corporation . . . . . . . . . . . . . . . . . . . . . . . . . . . . Taxes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Buy-Sell Agreements. . . . . . . . . . . . . . . . . . . . . . . Insurance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Workman’s Compensation . . . . . . . . . . . . . . . . . . . . Liability Insurance . . . . . . . . . . . . . . . . . . . . . . . . Employee Compensation Programs . . . . . . . . . . . . . . . . Medical/Dental/Optical/IRA . . . . . . . . . . . . . . . . . . . 401K/IRA/Retirement Benefits . . . . . . . . . . . . . . . . . Project Bonuses . . . . . . . . . . . . . . . . . . . . . . . . . Milestone Bonuses . . . . . . . . . . . . . . . . . . . . . . . . Royalties. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Stock Options . . . . . . . . . . . . . . . . . . . . . . . . . . . Trademarks and URLs . . . . . . . . . . . . . . . . . . . . . . . . War Chests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv Contents Chapter 28 Outsourcing Music . . . . . . . Music for Games . . . . . . . . . . . . . . . . When to Think About Music . . . . . . . . Music Formats . . . . . . . . . . . . . . . What Is Better Than MIDI? . . . . . . . . Digitized Sound Formats . . . . . . . . . . How Do You Break Down the Music Bid? . . Score Music for Triggered Events . . . . . Exploration and Ambient Music . . . . . . Chase/Battle/Hunting Music . . . . . . . . Jump Lists . . . . . . . . . . . . . . . . . . Menu Music . . . . . . . . . . . . . . . . . How Many Minutes Do You Really Need? Live Performance? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339 339 339 340 341 342 343 344 344 345 345 345 345 346 Chapter 29 Outsourcing Voice . . . . . . . . . . . . . . . . . 353 Interview with Chris Borders . . . . . . . . . . . . . . . . . . . . 353 Voice-Over Script for the Orc Peon from Warcraft III . . . . . . . 360 Outsourcing Sound Effects . . . . . . . . . . . . 363 Interview with Adam Levenson. . . . . . . . . . . . . . . . . . . 363 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369 369 369 370 370 371 371 371 372 372 373 Chapter 30 Chapter 31 Outsourcing Writing . . . . . . . . Computer Game Writing . . . . . . . . . . . . . Know Your Game; Know Your Business . . . Brevity is Bliss . . . . . . . . . . . . . . . . . Speak the Speech I Pray You. . . . . . . . . . On Dialogue Trees . . . . . . . . . . . . . . . Use Story as a Reward . . . . . . . . . . . . . The 80 Percent Stereotype Rule. . . . . . . . Hint, Hint, and Hint . . . . . . . . . . . . . . Expect Schizophrenia. . . . . . . . . . . . . . If You Have Time in a Bottle, Don’t Uncork It Chapter 32 Chapter 33 Outsourcing Cinematics and Models . . . . . . . 375 Interview with Mark Gambiano . . . . . . . . . . . . . . . . . . . 376 381 381 381 382 382 383 384 384 Outsourcing Motion Capture and Animation . . . Animation in Games . . . . . . . . . . . . . . . . . . . . . . . . . Key Framing . . . . . . . . . . . . . . . . . . . . . . . . . . . Motion Capture . . . . . . . . . . . . . . . . . . . . . . . . . . How Does Motion Capture Work? . . . . . . . . . . . . . . Cleaning up the Motion Data . . . . . . . . . . . . . . . . . Planning Your Motion Capture Shoot . . . . . . . . . . . . . . Best Use of Motion Capture . . . . . . . . . . . . . . . . . . . Contents xv Chapter 34 Fan-Generated Material. . . . . Game Development with Your Fans . . . . . Design Critique . . . . . . . . . . . . . . . Levels and Missions . . . . . . . . . . . . 3D Models. . . . . . . . . . . . . . . . . . Other Potential Activities to Outsource . . Legal Matters When Working with Fans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387 387 387 388 390 390 390 Appendix A Suggested Reading . . . . . . . . . . . . . . . . . 395 Project Management. . . . . . . . . . . . . . . . . . . . . . . . . 395 Game Industry . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396 Software Development . . . . . . . . . . . . . . . . . . . . . . . 398 Appendix B The Art Institute of California— Orange County . . . . . . . . . . . . . . . . . . . 401 Background. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401 Game Art & Design Bachelor of Science Program . . . . . . . . 402 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405 This page intentionally left blank Foreword It is a great honor to write a foreword for a book on game production, as this is a subject that is very close to our hearts. We have played a very small part in helping Erik with this book—he has accomplished a Herculean task in a relatively short period of time. We believe this book will serve as an excellent foundation for mastering the art of game production. A multitude of books have been written on the specific disciplines of art, programming, and design for games, but few, if any, have ever tackled game production as a topic. Perhaps this is because there isn’t a standardized way of referring to production in a manner similar to programming and art. Programming is done in C and C++ and usually follows standards that have been carefully crafted over many years. Art uses both traditional media and a narrow range of digital art tools, such as 3D Studio Max and Maya, and is often practiced by individuals with formal art training at their disposal. Perhaps game design is most similar to game production in that, until recently, there haven’t been formal programs in game design, and it is somewhat of an “arcane art” that could be realized in any potential medium. At the current time there aren’t any formal training programs for game production, though there are various courses available in project management. Project management doesn’t fully encompass the skills needed to manage game development, but it does provide some. Appropriately, this book includes elements of project management, engineering discipline (a tribute to Erik’s engineering background), and a lot of common sense (an essential ingredient in game production). Erik explained that his goal with this book was to fully realize the discipline of game production in a formal, yet widely appealing treatment. We were quite impressed with his ambition, as we’ve learned over the years (via our work on games like Baldur’s Gate, MDK2, Neverwinter Nights, and Star Wars: Knights of the Old Republic) that game production is a huge area. Erik further explained that he was going to provide additional information on topics such as outsourcing and detailed production frameworks. During our review of the manuscript, we learned a number of things that we’re going to be able to apply to development at BioWare. We’re also more excited than ever in seeing the final work with all of the graphs, diagrams, and illustrations accompanying the text. xvii xviii Foreword In conclusion we believe you, the reader and presumed game producer or game developer, will learn a great deal by reading this book. Its contents cover a wide range of topics and contain pearls of knowledge that will be of value to not only new game producers but also to experienced game developers. Read and enjoy! Dr. Greg Zeschuk and Dr. Ray Muzyka Joint CEOs and co-executive producers, BioWare Corp. Preface Who Is This Book For? This is a book about the making of digital interactive entertainment software— games! Specifically, this book is for people who want to lead the making of games: programmers, designers, art directors, producers (executive, associate, line, internal development, external development), project managers, or leaders on any type of entertainment software. n Are you a talented individual working on a mod to your favorite commercial game who needs to understand how a game is put together? n Are you working with a small team across the Internet on a total conversion like Day of Defeat that will grip gameplayers and game developers alike—but are wondering how to motivate your team members and articulate your vision for your total conversion? n Are you running your first game, with six or more developers working on your game? n Have you been at work for a few months, and everything felt great at the beginning, but now you are wondering if you are on time? n Are you just starting your second game project and determined to plan it right this time? n Are you a successful executive producer who is now responsible for overseeing several projects and want to know how you can get more clarity on your project’s success? n Are you an external developer and want to know how you can best manage risks and meet your milestones? n Is your project late? n Are you a member of a game development team and have a vested interest in the success of this game? n Are you thinking of joining the industry as a producer and need a producer’s handbook? The point is there are many different types of people responsible and accountable for the production of a game project. xix xx Preface TE Team-Fly® AM FL Y This book gives you specific tools for the management of your game, methods to create a project plan and track tasks, an overview of outsourcing parts of your project, and philosophical tools to help you solve abstract production problems. The author’s personal experience producing the hit series Starfleet Command and other projects, as well as extensive interviews with many other producers in the game industry, backs up this advice with real-world experience. Games are incredible products of creativity requiring art, science, humor, and music—a true blend of the mind. Managing this effort presents the producer with many challenges, some specific and some vague. While this book will answer many specific questions and give guidance in some of the general ideas, the tough calls are still yours. Acknowledgments I have been very fortunate in the writing of this book and I was able to lean on quite a number of folks from the game development community to answer questions and supply material for this book. I would especially like to thank the following individuals: Chip Moshner, Jarrod Phillips, Jason Rubin, Kevin Cloud, Ken Levine, James Masters, Lorne Lanning, David Perry, Nate Skinner, Nigel Chanter, Steve Perkins, Chris Taylor, Trish Wright, Beth Drummond, and John Carmack. I would like to thank Chris Borders for his lengthy interview on voice in games; Adam Levenson and Tommy Tallarico for their interviews on sound effects and music; and Scott Bennie for his generous response on writing. I would like to thank Steve McConnell for writing all of his books on software project management. I would like to thank all of the employees of Taldren who entrust in me every day the responsibility to lead the team. At Wordware I gratefully thank Jim Hill for the opportunity to write this book and I also thank Wes Beckwith for being a wonderful development editor and so supportive of writing this book. I also would like to thank Beth Kohler and Dianne Stultz for the amazing editing job they performed. A most outstanding thank you to Greg Zeschuk and Ray Muzyka who have given so generously of their time and minds to make this book a much better book. My two dear partners, Sean Dumas and Zachary Drummond, are due my heartfelt thanks for all of their support and just plain kicking ass every day. And finally, I dedicate this book to my wife, Kai-wen, and my son, Kyle, who is younger than this book. xxi This page intentionally left blank Part I > > > > > > > > > > > > > > > > > Introduction to Game Development This page intentionally left blank Chapter 1: What Does This Book Cover? 3 Chapter 1 > > > > > > > > > > > > > > > > What Does This Book Cover? How to Make a Game Fairly audacious heading, huh? There are a lot of books out there that are introductions to C++ or Direct3D, or discuss the construction of a real-time strategy game. What these books do not cover is which development methodologies you should employ in creating your game and how to be smart about outsourcing portions of it. This book is not a vague list of good ideas and suggestions; rather it gets down and dirty and discusses failed and successful project management techniques from my own experience as well as the experience of a multitude of other development studios. First Have a Plan Games that have a poor development methodology (or none at all) take much longer than they should, run over budget, and tend to be unreasonably buggy. The majority of commercial games fail to turn a profit. Figuring out what your game needs to do is called “requirements capture.” This book will show you how to use formalized methods such as the Unified Modeling Language’s use case diagrams to quickly collect your requirements and communicate them effectively to your team and other project stakeholders. Even if you are working on a solo project, you must still take your game’s project planning seriously. A mere demo of your capabilities to show a prospective employer would be created with higher quality and with more speed if you follow the techniques presented here. These are just the earliest elements of an entire game project production methodology that is developed throughout this book. 4 Chapter 1: What Does This Book Cover? Organize Your Team Effectively Once you have a plan in hand, full game production commences. This is the most exciting time for a game project. Literally every day new features will come online, and on a healthy project, the team will feed itself with new energy to propel forward. This book discusses how to create task visibility so everyone knows what he or she needs to do and how far along the rest are in their tasks. Controlling feature creep, reaching alpha, and freezing new features are critical to finishing your game. All of the mega-hits in our industry kept their feature sets narrow and the polish deep. I will point this out again: The mega-hits such as Doom, Warcraft, Myst, Gran Turismo, Mario64, and The Sims are not small games; rather their feature set is small but polished to a superior degree. This book will show you how to get a grip on your features. If you think about it, teams with one developer must use their time even more effectively than a fat 30person production. All the methods of creating achievable tasks, measuring progress, and controlling features are even more critical for very small teams. Game Development Is Software Development Games are certainly special; however, a point I will be making repeatedly throughout this book is that game development is software development. Games are software with art, audio, and gameplay. Financial planning software is software that is specialized for financial transactions and planning, expert systems are software with artificial intelligence, and cockpit instrumentation is software dedicated to flying an aircraft. Too often game developers hold themselves apart from formal software development and production methods with the false rationalization that games are an art, not a science. Game developers need to master their production methods so that they can produce their games in an organized, repeatable manner—a rigorous manner that creates great games on budget and on time. Where to Turn for Outside Help The game industry is maturing rapidly. With this growth, outside vendors that are experts in the fields of cinematics, character modeling, motion capture, sound effects, voice-over, language localization, quality assurance, marketing, and music composition have produced mature, cost-effective solutions for the largest to the smallest team. Do you know how many moves you need to capture for your game or how much they will cost? Do you need to record in high fidelity 120 frames per second, or will buying a library of stock moves be the best solution? I will show you how to specify what you need and give you an idea of how the bid will break down in costs. Interviews by major vendors in these areas will highlight major gotchas where projects went afoul and explain how to avoid them. Chapter 1: What Does This Book Cover? 5 How to Ship a Game So you have finished your game, eh? You’ve coded it all up and played through it a bunch, and your friends like it, but how do you know when it is ready to ship? I will show you how to track bugs, prioritize your bugs effectively, task your bugs, and review your final candidates for readiness. All game projects can benefit from beta testing. I will show you how to effectively solicit help from beta testers. Respect them and you will be repaid in help beyond measure. Let your beta testers lie fallow or fail to act meaningfully on their suggestions and your game will suffer. Beta testers are project stakeholders too; you must communicate with them effectively, explain to them your decisions, and show strength of leadership. Post-Release After a game ships you will often have a responsibility and an opportunity to support your game. This is especially true for the PC game market where it is possible to patch bugs, fine-tune the balance, and add new features or content. The new content can take the form of free downloads or larger packages that can be sold as expansions to your game. These are the straightforward tasks; true mega-hits transcend the status of just a game to play through and become a hobby. Enabling players to modify the game through the creation of new levels, new modules, new missions, or even total conversions keeps your game alive far beyond the life expectancy of a game without user-extensible elements. Pioneered to great success, id Software’s Doom and Quake series coined the term level designer as an occupation. Arguably, the greatest strength of Chris Taylor’s Total Annihilation was its aggressive design for user modification. Chapter 9 discusses the technical design, and it is here, in the earliest stages of architecture for your game, that you must plan for user modification. Waiting until the end of your project is not a valid method for adding user-extensibility to your game. Fan communication is critical to long-term success; set up an Internet message board for your fans to trade ideas, tips, gripes, rants, stories, challenges, and new content. Success and the Long Race The deeper message I am presenting in this book is that successful game making is a long race rather than a sprint to fast cash. Any attempt to take a shortcut for poor motives will manifest itself in a sickly, failed game project. Take your time to figure out the context of your game project. Discover why you are making this game. What is the vision? What are your true profit goals? Are they reasonable? What should you accomplish in this game? Where does this game you are making fit into a chain of game projects? 6 Chapter 1: What Does This Book Cover? How to Use This Book I suggest you first lightly skim through the entire book cover to cover to get a cursory exposure to formalized game development. Parts I and II discuss the challenges of game development thoroughly and introduce you to effective methods of game development to use on your project. The early chapters of Part III should be read thoroughly at the beginning of your game project to create a detailed project plan that will give your project the best start possible. Part IV is a resource guide to getting outside help on your project. This material should be reviewed carefully in the second half of your preproduction phase to flesh out your production plan. Part III should remain handy during production to help with organizing your team, wrestling with Microsoft Project, Unified Modeling Language, Excel, and other tools for measuring progress, and for controlling the scope of your project. Review the later chapters of Part III as production reaches alpha and it is time to figure out how to ship your game. The methods presented in this book have been boiled down in a distilled format in the Game Project Survival Test included in Chapter 4. Chapter 2: Why Make Games? 7 Chapter 2 > > > > > > > > > > > > > > > > Why Make Games? To Share a Dream Creative people love to share their dreams, thoughts, and worlds. Artists want to show you the world, musicians want you to feel the world, programmers want you to experience the world, and game designers want you to be there. Games are deeply rewarding because they appeal on so many different levels: They are stories to be caught up in, action sequences to live, stunning visuals to experience, and they challenge our minds by exploring our strategy and tactical skills. Games hold the unique position, of all the different entertainment mediums, of having the most interactivity with the audience. This is a very special quality; it makes the player the most important part of the story—the hero. Novels are interactive with the reader, as no two readers will visualize a narrative in the same way. Music is interactive for the rhythm, mood, and inspiration to dance that it charges humans with. Games are very special—only in a game can a player try different actions, experience different outcomes, and explore a model of a world. Games Teach Games and stories are deep elements to backgammon. Wei-Ch’i, or Go, can of human culture. Peek-a-boo and its be traced back by one legend to 2200 more sophisticated cousin hide-and-seek teach the elements of hunting prey and evading predators. The oldest complete game set discovered so far is the Royal Game of Ur, an ancient Sumerian game dating back to 2500 B.C. The rules for this game are unknown, but the conjecture is that it was a betting game about moving a piece around a track of squares, perhaps as a very early predecessor The Royal Game of Ur with permission from James Masters 8 Chapter 2: Why Make Games? B.C. China where Emperor Shun supposedly used the game to train his son for assuming leadership of the state. Chess has a rich history throughout the Middle Ages, the Renaissance, and through to modern times as the most celebrated game of strategic thinking. Longer histories of games are available; the point I am making here is that games have held an intimate role in our intellectual growth from the earliest ages. We modern game makers are carrying on an honorable, historic role. Game Genres Satisfy Different Appetites Electronic games are usually described by their genre—strategy, adventure, role-playing, action, and simulation. These genres are a direct reflection of the source material for the game. Military and sports simulations; gambling, parlor, and puzzle games; storytelling; toys; and children’s games comprise some of the major branches of influence for the creation of electronic games. Modern computer games have a rich history; some of the earliest games (1970s) were text adventure games such as Adventure, crude arcade games like Pong, and a little later, multiplayer games such as NetTrek. These early games explored storytelling, strategy, tactics, and the player’s hand-eye coordination. The sophistication of these games was, of course, limited by technology—a limit that is constantly being pushed back. Gambling, Puzzle, and Parlor Games Games evolved from elegant board games full of culture to a wide variety of wagering games involving dice or TE Background and influences on modern game genres AM FL Y cards. Games like Parcheesi and Scrabble took solid form during the 1800s and early 1900s. Parcheesi is the father of board games and requires the players Team-Fly® Chapter 2: Why Make Games? 9 to navigate their tokens around the board like Monopoly and Candy Land. These games themselves have been directly ported as electronic games, but it is the fast-paced puzzle games like Tetris that have developed new ground in this genre. As I type these words, over 110,000 people are playing straightforward conversions of the classic card and board games online at Microsoft MSN Gaming Zone (http://zone.msn.com/ql.asp). These games have entertained families and friends throughout the ages and teach deduction, probability, and social skills. The folks at Silver Creek Entertainment (http://www.silvercrk.com) have taken the concept of spades and hearts and have crafted the finest versions of these games, complete with a rich set of features for social interaction including chat, ratings, and blasting your opponents with fireballs. One of the coolest parlors (in my opinion) happening right now is the Internet Chess Club (http://www.chessclub.com) with over 1,000 players currently connected and 26 Grand Masters and International Masters playing online. The ICC boasts an impressive chat system, automated tournaments, over 30 flavors of chess, anytime control, and impressive library and game examination features. Automated chess courses are broadcast throughout the day, and many titled players turn their mastery into cash by teaching chess using the shekel—the unit of currency on the ICC. It is an exciting place where you have the choice of watching GMs and IMs or playing in tournaments around the clock. Instead of dusty annotated chess columns in the newspaper, try some three-minute blitz action with the best players in the world. A partial listing of games and gamers on Microsoft’s Gaming Zone A dwarf and a fireball from Silver Creek Entertainment’s Hardwood Spades 10 Chapter 2: Why Make Games? the obligatory features of impressive 3D plane graphics, great looking scenery, and a realistic flight model, the truly impressive features of X-Plane involve its expandability. Hundreds of planes and other features created by devoted fans are available for X-Plane, including real-time weather that is downloaded to your computer while flying! The author put Various windows of the Blitz interface to the Internet Chess Club his time into creating the first simulation of what it would be like to fly on Mars: real Military and Sports Simulations flight with the gravity, air density, and Games have long been providing simuinertia models of flight on Mars. lations of real-life experiences that many of us do not get to experience in daily life. There are simulations for white-water kayaking, racing minivans at night on the streets of Tokyo, fantastic-looking detailed professional football simulations, skateboarding simulators, star fighter sims; in short, any sport, military action, or transportation method is a good candidate for an electronic simulation. Flight simulators have been the staple of computer simulations since the early ’80s. Microsoft enjoys the #1 spot with Microsoft Flight Simulator, A screen shot collage from X-Plane which they release new versions of every even-numbered year—the latest Through the ’70s and ’80s Avalon being FS 2002 (http://www.microsoft.com/ games/fs2002). Microsoft Flight Simulator Hill produced a vast array of detailed military board games that covered all has a huge following including hunaspects of war making from the Bronze dreds of virtual airlines and air traffic Age to the Jet Age. Avalon Hill’s crowncontrollers, and half a dozen or so books are available for Flight Simulator. ing achievement is perhaps the most Austin Meyer of Laminar Research detailed board game ever created: Advanced Squad Leader (ASL). ASL is is the author of the most realistic and also the most detailed squad-level miliuser-extensible flight simulator, XPlane (http:// www.x-plane.com). Aside from tary board game simulation ever Chapter 2: Why Make Games? 11 A screen shot from the real-time weather display for X-Plane Virtual airlines from X-Plane developed. Countless modules expand the game and the rules to take into account the differences of individual operations in World War II. There are zillions of rules (and errata!) for everything from ammo types to night combat rules. Military buffs have been playing war games for hundreds of years, but the developments that led to ASL carried forward into electronic gaming. Currently there is a rage going on about WWII squad games such as Microsoft’s Close Combat and Cornered Rat’s World War II: Online. The most hardcore of them all is Combat Mission: Barbarossa to Berlin by Battlefront.com. My company, Taldren, was founded on the success of our team’s Starfleet Command game, which is a 3D realtime interpretation of the rule set of Star Fleet Battles from Amarillo Design Bureau. Star Fleet Battles is a detailed simulation of starship naval combat based on the Star Trek television show and was created by Steven Cole. The board game translated well into a real-time 3D strategy game in part because the pen and paper board game itself broke the turns of the game into 32 “impulses” of partial turns to achieve a serviceable form of real-time simulation. The game itself was usually played as a scenario re-enacting a “historical” battle between star empires of the Star Trek universe. The game was so detailed in its mechanics a simple cruiser-on-cruiser skirmish could take two to fours hours to resolve, and a fleet action such as a base assault was a project for the entire weekend and a bucket of caffeine. We developed the Starfleet Command series that draws upon this rich heritage and delivers a compelling career in one of eight star empires or pirate cartels. As the players get caught up in epic struggles between the star empires, they earn prestige points for successful completion of their missions, which can be used to repair their ships, buy supplies, and upgrade to heavier class starships. This electronic game blends a television show telling the story of exploring the galaxy with the detail of a war game. 12 Chapter 2: Why Make Games? second half of the twentieth century to become the dominant market of fiction. Reading a novel is wonderful, but would it not be better to slay the dragon yourself and take the loot home to your castle? In the early ’70s, Gary Gygax created Dungeons and Dragons and showed us how to slay the dragon. Dungeons and Dragons was very special because you did not compete against the other players; rather you acted or role-played a character in a fantasy world. You wrote a backstory for your elven ranger, what motivated him, why he must slay the orcs of the Fell Lands. You then joined up with the characters of your friends and roleplayed through an adventure run by your Dungeon Master, or referee. Dungeons and Dragons has been played by virtually everyone in the game industry, and it is a keystone of the role-playing game genre. Text adventures such as Zork and graphic adventures such as the King’s Quest Role-Playing Games series gave us choices for how the No discussion of game making could be story would turn out. As capabilities complete without discussing storytell- expanded, breakthrough games such as ing. Sitting around a fire and spinning a Bard’s Tale, written by the infant Intertale is one of the oldest forms of enter- play and published by Electronic Arts, tainment. Shamans acted out roles as were later followed up by important gods, animals, and warriors to explain games like the Ultima and Wizardry our world, teach us history, and to fuel series. Role-playing games took a brief our imaginations after the sun went slumber in the early ’80s when firstdown. With the advent of writing, person shooters dominated the PC authors could now tell stories across market, and the format of the computer time—longer, deeper stories than a sin- RPG remained fairly stale in the early gle dry throat could repeat. J.R.R. ’90s. Starting around 1997 role-playing Tolkien’s Lord of the Rings trilogy: Here games made a big comeback in the we drank wine with nearly immortal form of three hugely important games: elves, fought epic battles with orcs, and Baldur’s Gate developed by BioWare, saved the world from ultimate evil Diablo developed by Blizzard, and through careful use of a ring. Science Ultima Online developed by Origin. fiction and fantasy exploded in the Baldur’s Gate brought us a gorgeous game with intuitive controls and Car racing has been a staple of games from the days of Monaco GP and Pole Position in the arcade to the state-of-the-art Gran Turismo 3 by Sony. Gran Turismo 3 features hundreds of hours of gameplay, the most realistic driving physics model, and graphics so compelling you can feel the sunlight filtered through the pine trees. Electronic Arts, the largest software company in the games business, sells about $3 billion in games a year. Electronic Arts is both publisher and developer of countless games dating back to the early ’80s. EA has done very well across all platforms and all genres; however, it is the simulation of sports—professional sports—that is EA’s cash cow. Madden NFL Football (http://madden2002.ea.com) has been published for years and has been released on every major platform including the PC, PlayStation, PlayStation 2, N64, Game Boy Color, GameCube, and Xbox. Chapter 2: Why Make Games? 13 mechanics and lavish production values that brought the Dungeons and Dragons world of the Forgotten Realms to life. Diablo stunned the game industry with the simple and addictive gameplay of the tight user interface and online multiplayer dungeon hacking. Ultima Online was the first commercially viable massively multiplayer role-playing game. I spent probably 80 hours of my life there, mining virtual iron ore to get ahead in a virtual economy where I paid a real $10 a month for the privilege of exploring my mining fantasies. Looking back to pen and paper role-playing games and fantasy fiction, I am excited to see the future of roleplaying games with the release of Neverwinter Nights developed by BioWare, where the tools of game mastering are part of the game. Scores of players will participate together in user-created adventures online. These online role-playing games are fantastic in scope compared to the multi-user Dungeons available on Unix systems on the Internet, but the story experience is just as compelling. I look forward to seeing the massively multiplayer virtual reality games as depicted in Tad Williams’ Otherland fiction series, where we become true avatars. Gas Powered Games’ release of Dungeon Siege, building on the groundbreaking immediacy of Diablo, will be the slickest action/RPG today with breathtaking 3D graphics and strong online multiplayer matchmaking that will satisfy the dungeoneer in all of us. Youth Making Games You have to have the bug to make games. The talent usually begins at a young age. Like countless other game developers who made goofy games on early computers, I had a Commodore Vic20 and C64 on which I created text adventure games and crude bitmap graphic maze adventures. In fourth grade I produced a fairly elaborate board game series that involved adventuring through a hostile, medieval fantasy world with various characters very similar to the Talisman board game. In eighth grade my friend Elliott Einbinder and I created a wireframe, first-person maze game; you used the keyboard to navigate through the maze. A most embarrassing flaw was in our maze game: We could not figure out how to prevent the player from cheating and walking through the walls! We kept asking our computer science teacher how we could query the video display to find out if we drew a wall. We had no concept of a world model and a display model! On Money In this whole discussion I have not talked about the money to be made in making games. Game making is both an art and a science. If you are honest with yourself, your team, the customer, and to the game, you will make a great game. In all art forms, excellence is always truth. Honesty, truth, and clarity are all interrelated, and they are important not because of moral standards; they are important because only with the 14 Chapter 2: Why Make Games? ruthless pursuit of a clean, tight game can you hope to make a great game. The rest of this book will focus on how to get maximum value for your development dollars with outsourcing, how to decide which features to cut, and how to track your tasks; all these activities are heavily involved with money. That being said, look deeper and understand that I am helping you realize the true goals for your game project and to reach these goals as efficiently as possible. Great games sell just fine, and the money will come naturally enough; focus on making a great game. Why Make Games? You should make games because you love to. Making a game should be a great source of creative release for you. You love to see people enthralled by your game, playing it over and over, totally immersed in the world and the challenges you have crafted for their enjoyment. You should make games if there is something fun you can visualize in your mind, something fun you would like to experience, and you want to share that experience with others. Chapter 3: What Makes Game Development Hard? 15 Chapter 3 > > > > > > > > > > > > > > > > What Makes Game Development Hard? The Importance of Planning What does it take to make great games? Brilliantly optimized graphics code? Stunning sound effects, clever artificial intelligence routines, lush artwork, or simply irresistible gameplay? Well, you need all of that of course, with gameplay one of the most important factors. However, behind the scenes you are going to need a trail guide and a map to get there. You might be working alone on a great mod to a commercial game, or you might be working with an artist on a cool online card game, or you might be the director of development at Blizzard. The size of your project or your role does not matter; you still need a plan to create your game. Why must you have a plan? With the smallest of projects the plan will likely be to get a prototype of the game going as soon as possible and then just iterating and playing with the game until it is done. This method works well if the game you are making is a hobby project, or your company is funded by a seemingly unlimited supply of someone else’s money and you are not holding yourself financially accountable. Very Few Titles Are Profitable Many people do not realize how few games are profitable. In 2001 over 3,000 games were released for the PC platform; it is likely only 100 or so of those titles turned a profit, and of those only the top 50 made significant money for the developers and publishers. In 2000 an established developer in North America would likely receive between $1 million and $3 million in advances paid out over 12 to 36 months for the development of a game. The typical publisher will spend between $250,000 and $1.5 million in marketing The darkened boxes represent the number of successful games published each year. 16 Chapter 3: What Makes Game Development Hard? and sales development (“sales development” is the euphemistic term for the money the publisher must spend to get the game actually on the shelf at the retailer and well positioned). The box, CDs, maps, manual, and other materials in the box cost between $1.50 and $4.00 collectively. The royalties an established developer could expect vary widely, from 10 to 30 percent, depending on many factors including how much of the financial risk the developer is assuming and the types of deductions to the wholesale price. Let’s take a look at what these numbers mean for a game that has an average retail price of $35 over the life of sales in the first 12 to 24 months after release. Table 1 summarizes the financial assumptions behind this hypothetical project. Table 1—PC Game Project Financial Basics Average Retail Price Wholesale Price Developer Advance Developer Royalty $35.00 $21.00 $1,500,000 15% 500,000 Units to Break Even? Take a long hard look at Table 2. Notice that not until 500,000 units have been sold does the developer see a royalty check. This is a $75,000 check that is likely to be issued to you between 9 and 18 months after release of the title. The conclusion from this is that royalties alone will not feed you and your team post-release. “No problem,” you think, “my title will sell millions!” Unfortunately, even good games don’t always sell many units. As an example, the excellent developer Raven sold a little over 30,000 units of the strong game Hexen II. Messiah, the longanticipated edgy first-person shooter, saw fewer than 10,000 units sold in its first three months (most games make the large bulk of their sales in the first 90 days of release). Fallout 1 enjoyed a loyal fan following and strong critical reviews and sold a little more than 120,000 units in its first year. The author’s Starfleet Command 1 sold over 350,000 units its first year without counting the Gold Edition and the Neutral Zone expansion. However, the sequel, Starfleet Command 2, has sold 120,000 units in its first six months of release. Sure, Diablo II from Blizzard enjoyed over 2 million units of orders on day one of release, and The Sims has been in the top 3 of PC Data for almost a year and a half. These titles have clearly made a ton of money. In fact, those orders that Blizzard had for Diablo II on day 1 had a value that exceeds the market capitalization of Table 2—Game Project Payoffs at Various Sales Targets Units 10,000 30,000 100,000 200,000 300,000 500,000 1,000,000 2,000,000 Royalty $ 31,500 $ 94,500 $ 315,000 $ 630,000 $ 945,000 $ 1,575,000 $ 3,150,000 $ 6,300,000 Less Advance $ (1,468,500) $ (1,405,500) $ (1,185,000) $ (870,000) $ (555,000) $ 75,000 $ 1,650,000 $ 4,800,000 Chapter 3: What Makes Game Development Hard? 17 Interplay Entertainment1—a publisher with a rich publishing history spanning over 15 years. Employee Compensation and Royalties Table 2 has other implications. Many development houses share royalties they receive with their employees by some fraction. Many developers go even further and offset the often too-low salaries paid in the highly competitive game business with overly optimistic promises of future royalty payments. These promises are meaningless in many cases: After the employees crunch through development and release and even during post-release, supporting the fans, these expectations of monetary rewards for their labor turn out to be false. Then these employees turn from energetic, highly productive creative developers to disenfranchised employees looking for a new job. What Are the Financial Expectations for Your Game? A recurring theme throughout this book is managing expectations of all project stakeholders through highquality communication that is clear and honest. That is why I am presenting this sobering information so early in this book. You must be clear about why you are creating your game. Do you expect to make a profit? Are you depending on the royalties (or direct sales in the case of software sold as shareware or by other direct sales methods) to support yourself and your development staff? Is this project only a hobby and any money it produces a happy bonus? Is a publisher funding the project or do you have an investor backing your project? Knowing your financial expectations—not your hopes and dreams—for your game project is critical to achieving success. Establishing these expectations will determine the scope of the project. With the scope of the project in mind, an estimation of the number of developers required to create the game and how long it will take is established. This estimate should then be compared to the financial goals one more time to establish a baseline for cost, time, and scope. The Scope of the Game Must Match Financial Parameters Most game projects fail to meet their financial expectations because the developers fail to articulate clearly and honestly what the implications of their expectations are. This is such an obvious statement, but virtually every game project I know of suffers from a disparity between what the expectations are for the project and the resources and time allocated to the project. Some of the very well-endowed developers such as Blizzard, BioWare, and id are famous for the “When it’s done” mantra. There is little doubt that a project from Blizzard, BioWare, or id will be of the highest quality and most 1 This statement sounded a lot more impressive when I wrote it in the summer of 2001; as of October 2002 Interplay has been delisted from NASDAQ. 18 Chapter 3: What Makes Game Development Hard? undoubtedly be very profitable. However, Blizzard, BioWare, and id also have a large amount of working capital on hand and have dedicated that working capital to making killer games. If you do not have an unlimited supply of working capital on hand, then I strongly suggest you take on a different mantra than “When it’s done.” Most likely you have a budget of both Why Your Game Should Profit Part II, How to Make a Game, will show how we take these baselines and develop a project plan and then execute the development of a game project. Beyond just running a single game project, I will discuss how your game project should fit into a greater plan of growth for yourself, your company, and/or your team. The dot-com era has distorted many people’s expectations of what it takes to make a business. Too many dot-coms were based on business plans about gaining “mind share” or “market presence,” or were just plain hype. Many overnight millionaires were made, so this style of business creation certainly worked for some, but for the vast majority of dot-coms, bankruptcy and bust was the end. These dot-coms failed to create a product or service that people would actually pay money for and be able to deliver it in such a manner that they could make a profit. Making a profit is not an evil thing to do for a bunch of creative game developers. Making a profit enables you to store up capital to handle the period of time between projects. A capital reserve allows you to respond more gracefully to project slippage due to unexpected turnover or other TE AM FL Y Feature Storm time and money to work with, so what you need to do is figure out what is the “best” game you can make within budget. Remember, id founders once created games for $6 an hour for a long-forgotten publisher, SoftDisk, and Blizzard once worked as a developer for Interplay. There are steppingstones on the way to greatness; too many developers try to take the gaming world by storm in one ambitious step. unforeseen events. Profit allows you more tactical and strategic maneuvering room for your game company. This store of capital enables you to make more ambitious games in the future, retain employees, hire new talent, and make capital improvements to your workplace for greater efficiency. Too many game developers pour their heart and soul into game projects that have no real likelihood of making a profit. Maybe you do not care about profit. Maybe it is of secondary or even tertiary importance to you. I still urge you to run your game project with the rigor and the earnestness of a small business that needs to deliver on expectations, on budget, and on time. Following are two unprofitable attitudes when approaching game development. Attitude #1: “Hey! What about quality? You are leaving me cold here, Erik. My game is going to rock; it is going to be massively multiplayer, with magic, martial arts, and small arms combat. I am going to have vehicles, and you can go to any planet you want and even fly a starship to get there! Erik, you dork, of Team-Fly® Chapter 3: What Makes Game Development Hard? 19 course my game is going to make a ton of money; people are going to lay down $10 a month to play it, and I will port it over to the PS2 and Xbox and pick up the juicy console money too. Sheesh! Making a profit, that is going to be a side effect of my vision, Erik. I do not need to worry about that!” What is wrong with attitude #1 is that the designer has not looked into the costs for developing every feature under the sun. There is a reason why Warcraft is a tight game about managing humans and orcs gathering stone, gold, and wood. There is a reason why Quake is a tight game about first-person combat. Creating a game that people want to play means fully delivering on every expectation you create in your game design. If your game design has martial arts combat, then your fans will want a very playable martial arts simulation. If you also have starfighters to pilot in your game, your game better be competitive with FreeSpace 2 in its execution of starfighter combat. Otherwise you will end up creating a bunch of open expectations that you will not be able to fulfill. The market will crush you for creating unmet hype. If the Game Is Worth Making, Make It Excellent Attitude #2: “I am just making a little spades game to get my feet wet. I am never going to show it to anyone, and no one is going to play it, so who cares if I make a profit?” The problem with attitude #2 is that it ignores the strong wisdom that says if something is worth doing, it is worth doing well. A weak demonstration of your programming skills will demonstrate that you are a weak programmer. An incomplete game design document will demonstrate that you make incomplete designs. Art that does not appear competitive shows that you do not have the artistic talent to compete. Excellence in Spades Take a look at Hardwood Spades from Silver Creek Entertainment (http:www.silvercrk.com). This is by far the most polished execution of spades the world has ever seen. A core team of just three developers has put out an incredible series of classic card games, where the quality of the executed games is way over the top. They have added a ton of small, tight features and improvements to the playing of spades such as casting a fireball or a shower of flowers at another player. This spades game is multiplayer and is played 24x7 on servers hosted by these folks. They do not take advance money from a publisher but sell their games direct to the consumer online. They have slowly built up a following over the years and are now quietly selling hundreds of units a month for each of their titles. I have the utmost respect for these folks. They had a vision for creating the highest quality classic card games on the planet and have executed that dream step-bystep, building up their capital, fan base, and quality level as they went. Notice that they did not pitch the idea of the world’s most gorgeous card games for $2 million up front to a publisher and then go find an artist, programmer, game designer, and fan base. Instead, 20 Chapter 3: What Makes Game Development Hard? they released their first game, Hardwood Solitaire, in 1997, which had moderate success and enabled them to build upon this experience. I have no idea what their future plans are, but notice that they have built up a strong collection of popular titles and a successful brand, and are now in the powerful position of continuing to build up their brand and products, licensing their products for a distribution deal, or perhaps selling themselves in whole to a larger company to lock in a strong return on their years of investment. Game Making Is a Long Race of Many Game Projects Investing over time is what it takes to make it big in the game industry. It is a very long race in a very small world; do not burn any bridges, and try to make as many friends as possible along the way. Some of you may be familiar with the games I have produced—the Starfleet Command series. Some of you might say, “Hey, Erik, didn’t SFC1 and SFC2 have a bit too many bugs? How do you account for that? Oh, and didn’t SFC2 not ship with a functional Dynaverse 2, the hyped, massively multiplayer-lite metagame? If you are so wise, Erik, explain what happened.” No problem, hang on a moment and listen to what I have to say. This is a book wrought from my experience and the experience of other developers—experience of both success and failure. What I have to share with you in this book is not wisdom I received in college, nor did my boss train me when I first led a game project. This is hands-on, face-the-challenges-as-yougo advice. Much of what I have learned has come from taking the time to analyze what happened and discussions with my teammates and other game developers to figure out what went wrong and how we could have done better. In many ways this book represents a field manual of essential game production that I would have appreciated reading when I started leading game projects. Throughout this book I will discuss the Starfleet Command series and the decisions I have made along the way as a producer. You will be able to run shotgun and role-play an armchair executive producer! There are books out there that will attempt to teach you to design and program a real-time strategy game or write the rasterizer for a software first-person shooter. You can also find books telling you how to design and architect your game, and some books have made strong efforts as a resource guide for finding sources of art, music, and code. However, these books do not address how to make a game. Chapter 3: What Makes Game Development Hard? 21 A Brief History of Software Development How to make a game, I believe, is the most elusive question in the game industry. In fact, the software industry at large is relatively open and up-front about how immature the software engineering processes are as a whole. Take a look at After the Gold Rush by Steve McConnell for an excellent discussion of the much-needed maturation in the software industry. Much development in the software engineering community is going into improving the process of how we go about making software. During the ’60s and ’70s great strides were made in increasing the strength of the programming languages from Fortran and COBOL to C. During the ’80s the microcomputer created tremendous improvements in the programming workplace. Each developer could have his own workstation where he edited, ran, and debugged code. During the late ’80s and early ’90s the leading edge of the software development community got charged with the efficacy of objectoriented programming and the largeproject strength of C++. Improvements continued with integrated editors, debuggers, and profilers. Optimizing compilers have almost made assembly programming obsolete, and visual interface layout tools have made programming rather pleasant for business applications. With all of these fantastic improvements to the software development process, software project budgets have only gotten larger and have only slipped by longer amounts of time and by greater numbers. Overly Long Game Projects Are Disastrous Take a look at Table 3 listing game projects, how long they took to release, and the outcome. This table is a Who’s Who of games that have run horribly over budget, and only two games on that list have made significant money: The Sims and Baldur’s Gate. The best-selling game on the list, The Sims, has made and is continuing to make a huge fortune for Electronic Arts. Why is it that The Sims has made the most money on that list? Because Electronic Arts was very fortunate that no one else (that statement is worth repeating) no one in the entire PC game industry of some 3,000 titles a year for five years in a row has released a title even remotely competitive to The Sims, filling a vastly Table 3—Long Game Projects Stonekeep 1 Daikatana 5 years of development 4 years of development, fantastic cost overruns 5 years of development 5 years of development 5 years of development 3+ years of development 5+ years of development 5 years of development Weak sales Weak sales Messiah Max Payne The Sims Baldur’s Gate Duke Nukem Forever Stonekeep 2 Weak sales Just released Amazing sales Very strong sales Yet to be released Project cancelled Project cancelled Ultima Online 2 4 years of development 22 Chapter 3: What Makes Game Development Hard? underserved market of women who are consumers waiting for games to be designed for them. And with the right title EA can make tons of money due to its marketing and sales strength; this cannot be underestimated. Also note that Maxis released something like ten games in the sims genre and only two of these, SimCity and The Sims, have generated great returns over ten years. The rest of the sim-type games were relatively poor sellers. This is something that seems to be forgotten by a lot of people—that Will Wright has been experimenting with this type of game for ten+ years before hitting a home run with The Sims. Max Payne has just been released, and we need a little time to see how the market will respond to this adventure shooter with amazing graphics (I expect this game to do well). The other successful title on the list, Baldur’s Gate, had a number of delays and development extensions but ultimately was still successful: The Baldur’s Gate series (BG with its expansion pack and sequel/expansion pack) has sold nearly 4 million units worldwide. It came at the right time for role-playing games and was a quality title with a strong license (Advanced Dungeons and Dragons) behind it. As for the rest of the titles, they were simply too-little too-late titles that had to compete against stronger games that were produced faster and for less money. Or in the case of Stonekeep 2 and Ultima Online 2, there were millions of dollars of game development and even the hype of game magazine covers that the publishers had to walk away from when the games were cancelled! What Late Games Do to Publishers When projects run over, even by less than three years, they hurt the industry at large. Consumers are tired of being frustrated by overly hyped games that are late. The publishers are constantly attempting to make realistic financial projections to manage their cash flow and maintain investor confidence. With poor cash flow or low investor confidence, a publisher is often forced into publishing more titles. More titles mean each receives less attention at every stage of development. This in turn weakens the publisher more, as titles begin to ship before they are ready in order to fill gaps in the quarter. This creates a vicious feedback cycle that pressures the publisher to publish even more titles. Our Project Plan Behind Starfleet Command Interplay was impressed with our quick execution of Caesars Palace W95 while working for another developer, and after doing various contracting and working on our own demo of a game, we joined Interplay in the summer of 1998. Interplay presented me with running Starfleet Command and the opportunity to work with Sean, Zach, and other folks I had worked with before. We jumped at the opportunity to work on a big title at a big publisher. When we got into it, we realized that Interplay was a big company with many Chapter 3: What Makes Game Development Hard? 23 to earn Interplay’s respect so that they would trust us enough to fund a future game concept of ours. SFC itself was an exciting title for us to work on, but for every game project you must know why you are doing it. For Starfleet Command our goal was to create the most faithful, highest fidelity modeling of naval starship combat set in the Star Trek universe. We were not trying to make a Star Trek game, we were not trying to make a 3D game, and we were not trying to make a real-time strategy Starfleet Command game like StarCraft. As we worked on different games in production. Our sis- our vision statement, we developed the ter project, Klingon Academy, was term real-time tactical to describe our making impressive success in the dam- gameplay. Our game was all about tactiage effects of its 3D engine and its cine- cal starship combat. We did not send matic cut scenes. Starfleet Command, teams down to planets, we did not have on the other hand, was considered a the player act as a courier and carry niche game appealing only to the most goods across the galaxy, and we did not hardcore of game players—fans of Star allow the scavenging of enemy vessels Fleet Battles. This turned out to be a to build a Frankenstein ship. No, great advantage on several different instead you were a naval officer in one levels at the same time. The first benefit is that Brian Fargo, the founder and CEO of the company, left the project’s vision entirely in my hands while Klingon Academy received more of Interplay’s attention. The other benefit was of course the built-in base of Star Fleet Battles fans who had waited 20 years for a computerized version of their favorite, ultra-detailed naval starship simulation set in the The vessel library screen from Starfleet Command original series’ Star Trek universe. of six star empires carrying out combat missions on behalf of your empire. The Vision for Starfleet Command Over 1,000 starships were modeled Starfleet Command was my first big in our game, with over 100 missions to title to manage; I was very excited and test your tactics and strategy. The determined to do a good job. I wanted player role-played a captain enjoying a 24 Chapter 3: What Makes Game Development Hard? career of over 30 years in the service of Command was about, that was our goal, his empire. That was what Starfleet and we delivered on that. Constraints Give Much Needed Focus Starfleet Command went on to be a stunning success. The press at the time was stunned to see a Star Trek game that was actually fun. The secret to our success was following our vision. We had no budget for fancy movies to tell a story, so we did not try to create a game with a linear story line that depended on movies. Instead we developed a random mission/campaign generator with linear story missions embedded like raisins in pudding. You must look at every constraint on your project as an opportunity to focus your game on its key features. On Bugs Shipped in Starfleet Command High-quality games with ultra-low bug counts like Quake and Diablo sell very well. However, Quake and Diablo sell strongly for quite a few good reasons working together. We had a fixed timeline; in fact, the Starfleet Command project was already late before I took it over. After reviewing where the project was for two months, I decided on a delivery date of summer 1999 given a lot of extra programming and art resources. Interplay granted the resources but in turn needed the date to be unmoving. We had a project with a flexible feature set but a fixed timeline. We essentially put too many features in the game and coded too late into the production process. We were still coding heavily two weeks from final master and worked on the first patch all the way through manufacturing. We fixed so many bugs in the last three months of development that we honestly thought we had a game with a fairly low bug count and a ton of features. After a week of it being on the street, I developed a new realization of how high a quality standard software must have in order to work on anyone’s computer, in any manner the user could come up with. We did have to ship with known bugs though, and the consumers had to deal with those too. We were fast with the patches, and altogether the public enjoyed a game that was original and fun to play. Starfleet Command went on to sell over 350,000 units in its first year, and at that time at Interplay, SFC was the second most successful title, behind Baldur’s Gate developed by BioWare. Also it is a fact that there are more bugs inherent to games with more complex systems; for example, SFC is much more complex and detailed than Quake and therefore needs additional QA attention. Roleplaying games like BG are also more complicated and required additional QA time and completely different QA processes. Treating all games in an identical manner from a QA perspective is just plain wrong (but it happens all the time). Chapter 3: What Makes Game Development Hard? 25 Well-Met Goals Enable Future Successes Based on the success of Starfleet Command, Interplay’s management was very receptive to our pitch to do Starfleet Command 2 as a wholly independent developer. See Chapter 27 to see how we set up as Taldren and how we structured our company for the development of Starfleet Command 2. Strong Game Developers Have Strong Foundations A small chronicle of great games The above figure chronicles just a few of the most successful and influential games over the years. The Tension between Preproduction and Production Bridges for the most part stoically support their loads across their spans. Dams rarely burst, flooding entire cities. Why do civil engineering projects seem to be routinely successful when software engineering projects routinely go over budget, take too long, and generally underperform or are just buggy? The difference is in process and methodologies. Performing something complex that requires the efforts of many skilled 26 Chapter 3: What Makes Game Development Hard? humans over an extended period of time necessitates breaking up the large, complex task into a series of small, achievable, measurable tasks. Ideally, figuring out what you are doing should come before you do it; the game industry term for this phase of work is preproduction, or the vision or design phase. We have a name for it sure enough, but too many projects violate their preproduction phases and move straight to production. Twenty years ago preproduction would have been a sketch of the game screen on a napkin and a couple of experimental routines to get the idea straight. Ten years ago preproduction was largely about the art of the proposed game. Now preproduction is usually a playable demo. True preproduction would be the distillation of all the game’s requirements, an analysis stage to determine the implications of these requirements, a culling stage to meet the business parameters, and a detailed game, art, audio, and technical design to detail the requirements. Preproduction would still not be done, however, for these detailed game, art, audio, and technical designs would uncover new details about the project requiring another revision of the feature set to meet the business requirements. Any risky areas of the project need to be explicitly called out, and alternative plans need to be formulated to get around these risks. Finally the plan needs to be presented to all stakeholders including the development team, the publisher, and the marketing, press relations, and sales forces. Games are big productions, and successful games require the full effort of many individuals spanning many companies. In my opinion, preproduction is the most important stage of the project. I would like to see the day when a project spends a full 25 to 40 percent of its overall prerelease time in preproduction. During production there should be relatively few surprises. The developers should be able to work eight hours a day, take vacations, and pick up their children from school. Instead, the industry responds to the intense competition by compressing preproduction into the shortest period of time possible. There is no hype, celebration, visibility, or honor in the game industry as a whole for preproduction. In my opinion, everyone would make a lot more money if instead of 3,000 game projects being launched a year, 4,000 or 5,000 game projects could receive two to nine months of preproduction and get cancelled, and only the top 400 to 800 would get produced and released. Publishers’ net revenues would be five to ten times higher if their hit projects were not bogged down by four to ten failed projects. The Power of the Console The console side of the business does manage itself a lot stronger than the PC world in this regard. The answer lies in the hardware vendors; they do not allow a title to be released unless they approve. A console title must be presented to the hardware vendor several times along the way and can be sent back for revision or altogether cancelled by the hardware vendor with no Chapter 3: What Makes Game Development Hard? 27 recourse for the publisher except to work harder. This added rigor in the console world allows far fewer titles to be produced, but the net revenues across all console titles are reported to be seven times more profitable. Why Aren’t All Publishers Using Preproduction? If preproduction is so compelling, why isn’t every publisher using it? Actually publishers have a twist on this process, called green-light meetings. Some projects have only one at the beginning of a project; other companies have a series of green-light meetings acting as gates that the project must pass through. However, these meetings are just meetings. There are a bunch of executives with too much work to do trying to figure out if they should cancel a project or not. To help them make a positive decision, the developers, producers, and executive producers at the publishing house spend a lot of development energy making bits of software and art that hopefully make a striking impression on the executive’s mind. This is accurately enough called “eye candy.” eye candy are appropriate, but the eye candy should be presented in the context of an overall production plan. If this level of rigor were followed, we would all be making stronger games resulting in much stronger sales and much saner schedules. Unfortunately the experts you would need to employ would have to be so skilled that they would most likely be art directors or technical directors, or running their own development company. The usual process is that game projects are ignored by the executives in the early stages when there are other more pressing fires to be put out, or the executives tend to focus on what they see in the form of eye candy. The Process Is Changing The game development process is one of the hotter topics that publishers now JARGON: A green-light meeting is a look for in a developer. Microsoft, for meeting at which a body of decision instance, sends a solid team of experts makers at the publisher decide whether down to a prospective developer and or not to publish a game. interviews the house for a day or two. Instead of one of these green-light Microsoft also appears to be the pubmeetings, I think each game project lisher that respects preproduction the should undergo a green-light minimost by giving each project at least two phase where each portion of the proor three months of real, funded ject, such as art, game design, and preproduction. The actual presentation technical, present their detailed plan on to the executives of the preproduction how to get their job done to one or is more of a team affair involving the more experts in that field. It should be developer, the producers, as well as the composite findings of these experts early reports of something called that is shown to the executives. It could usability. be that diagrams, charts, concept Having far less development sketches, and even demonstrations of resources to tap than Microsoft, Eidos 28 Chapter 3: What Makes Game Development Hard? calls upon the heads of their various studios to pass judgment at the greenlight meeting. Each of these studio heads has a strong development background and his or her gut reactions are fairly good divining rods of a game’s success when you only have 20 minutes to review a title. Look for more publishers changing their project review process as they try to cull their failing projects before release, and ideally, early in production. A Strong Plan Makes Game Development Easy This is not a chapter of gloom and doom; rather this chapter points out the larger pitfalls in game development. The whole book is dedicated to taking a proactive, forward-looking approach to game development. Chapters 8 and 9 detail the role of the game design and technical design documents. Chapter 10 discusses how the game design and technical design documents are synthesized into a project plan. Chapter 17 delves deeper into the rigor that should be put into preproduction with an introduction to Unified Modeling Language in the form of use cases and how they are used to perform your requirements capture. Chapter 16 discusses how critical the game design document is in shaping the team’s vision for the game. If everyone knows what the game is supposed to be like, they will make it a lot faster and better. Chapter 16 presents specific steps you should take when constructing your game design document; other leaders in the game industry will discuss what material they think is critical in the game design document. Technical design is presented in Chapter 18, a thick chapter with a lot of discussion of large project objectoriented technical design. Unified Modeling Language is revisited here to see how it is used to model the software from different views, such as static views of deployment, packages and class diagrams, and the dynamic views of activity and sequence diagrams. Developing accurate time estimates is addressed in Chapter 19, including classic questions such as how much to pad or whether one should one pad at all. Wrestling all of this data together into a digestible project plan is discussed in Chapter 20. The Gravitational Pull of Feature Creep Even if you have the best-constructed production plan this industry has ever seen, your project still needs to be organized. Do not think that production is the time to go get your plan professionally printed and sent to all of your friends while you work on getting your A licenses in Gran Turismo 3. Rather, production is the time to put your plan to work; Chapter 22 tells you how to get a grip on feature creep. TE AM FL Y Team-Fly® Chapter 3: What Makes Game Development Hard? 29 Task Visibility for Team Motivation and for Progress Tracking Task visibility is my passion. There is a deep satisfaction I get as a producer when I know my team members know their own tasks and the tasks that the others have to do. When each person is humming along, tearing through the project with the utmost confidence in his or her team members, it seems like anything and everything can be done. As the leader of a team or a subteam, your job is to monitor this well-being. Too many times a project’s Gantt chart (discussed in Chapters 10 and 20) is posted on a wall and updated only once a month. Task visibility means a lot more than the manager keeping track of progress and reporting to the executive management. The development team is the most important customer to report the project’s progress. Chapter 10 gives an introduction to task tracking, while Chapter 21 provides detailed task management techniques from various top studios. Use Your Core Competencies and Outsource the Rest A large portion of this book is an in-depth guide to outsourcing parts of your development from cinematics and motion capture to music and sound effects. Figuring out what you should outsource is discussed in Chapter 12. Chapter 12 introduces outsourcing, and Chapters 28 through 33 give specific advice on where to get your outsourcing done and how to do business with these vendors. A Pitfall of Success—Fan-Requested Features and Changes Ironically, making a hit game brings with it the challenges of meeting a fan base with an insatiable appetite for more, bigger, faster, and cooler features. Endless debates discussing your game balancing skills and astonishing acts of generosity from your most dedicated fans will test the depth of your commitment to your game, which is now their game. Mastering the post-release fan relationship is a lot more than issuing a patch and crawling back into your cave of creativity. Now that your game has enjoyed success, it is time to open your shop door, so to speak, and take your relationship with the fans to a deeper level that will carry forward to your next title. Chapter 24 discusses the issues involved in this relationship and some specific advice from successful game developers. 30 Chapter 3: What Makes Game Development Hard? The Relentless Pace of Technology Game making is a creative art form that competes with other media such as novels, television, movies, and music. While technology has had dramatic effects on how music is recorded, how film is taped, how television is delivered, and even how a novel is typed, none of these other art forms have to compete with technology to nearly the pace game making does. Movies are probably the closest art form in scope, cost, and high-level production methods. That being said, camera technology stays stable for 20 years at a stretch, lights are lights, and microphones are microphones. Right now the movie industry is looking at using digital film, but again, this is technology that has been in regular use for 20 or more years. In the past 25 years that electronic games have been a consumer entertainment medium, they have gone through nearly countless technological evolutions including text adventures, 2D graphic adventures, turn-based strategy games, 3D action games, smooth-scrolling 3D action games, ray-casting engines, binary spacepartition engines, and I could go on and on listing the different game engines that have been created. Each new game must develop its own tools first and then create its content. Future add-on and expansion packs will often use the same engine, and in some cases the sequel will use a modified version of the prior game. It has become increasingly common in the last five years to license whole game engines such as Quake and Unreal to act as the foundation engine to build a game. A game requires not only a solid design but also a completed engine and tool path prior to entering the implementation or production phase; otherwise the inevitable result seems to be redoing work over and over, which is demoralizing, expensive, and a waste of time. This shifting engine technology is not seen in any other consumer software product. There is no consumer operating system, word processor, or spreadsheet that has required the computing power of the last five or ten years of Intel’s advances to the x86 line of chips. It is games that drive our voracious appetites for more RAM to hold our textures, gigabytes of hard drive space to hold our gigabyte installs, and the fastest CPU on the planet to simulate our fantasy worlds. The dark side of this technological advance on the PC side of the game business is that we do not know what hardware the consumers will have before they install and run our software. We do not know if they have 64 MB of RAM, 128 MB, or just 32 MB of main memory. We do not know if they have a 3D accelerator card with 8 MB of RAM, 32, 64, or no 3D card at all! We do not know if they will have enough space to install our game in its full glory, so we have multiple install options. We do not know if their graphics card chipset will support the subset of features we want for our game. We do not even know how fast the target CPU is. In fact we do not even know what operating system they will be running our game on. Sure it will be a Windows variant, but there must be big differences between Windows 95, Windows 98, Windows NT, Windows 2000, Chapter 3: What Makes Game Development Hard? 31 Windows ME, and Windows XP or Microsoft would not have put thousands of man-years into these operating systems. These operating systems have major differences on critical lowlevel functionality like how memory is accessed and protected, how timers are created, what their resolution is, and the efficiency of storing and retrieving data from the hard drive. There are people out there playing Starfleet Command 1 with the graphics options turned low on laptops with only a Pentium 90 MHz and no 3D card, and there are also folks out there with a Pentium IV 1.7 GHz with a GeForce 3 card that has 64 MB of memory just on the card. Depending on which metric you use, the Pentium IV 1.7 GHz is nearly twenty times more powerful than the Pentium 90. This is called Moore’s Law, stating that the computing power of computers doubles every 18 months. With all of these unknowns, we need to create a game that will run substantially well and deliver the same play experience on the greatest number of machines out there. This is where minimum requirements and clever use of scalability in performance-intensive features such as graphics and artificial intelligence comes to play. Hardcore games typically have the most aggressive schedule for culling older machines from the minimum requirements. This, however, cuts into sales for mass-market games, and a delicate balance exists between pushing the edge of the performance bar in order to gain exposure and adoption by the hardcore players, and planning for broad sales by supporting as many older systems as possible. Games that are strong examples of this are The Sims, StarCraft, and Baldur’s Gate I and II, which work on quite low-end systems. Much of their success in the mass market may relate to the fact that people with lower end systems can still play them. The final challenge in the fast pace of technological change is that your requirements will often change midproject or very late in your project. With less than six weeks to go on Starfleet Command 1, I was informed that Interplay signed a ten-product agreement to support AMD’s 3DNow chip set. With little time left before code freeze, we were forced to optimize just a handful of low-level vector and matrix routines to take advantage of the 3DNow feature set. The console market is considerably different. When you make a game for the PlayStation 2 you know exactly how fast it will be, how much video RAM you will have, and every other detail of the console at the time of producing the game. (Except when a developer is working on a game for a console that has not been released yet to the public. In the case of Taldren, we are working on an Xbox game, and I get packages from Microsoft every so often with a revision to the software running the box. At larger intervals the hardware itself changes.) This factor, combined with much more stringent QA from the console manufacturers themselves, makes console games practically bug-free in comparison to PC games. Console developers have a strategic advantage in that their platform is known and immutable, but also a disadvantage in that their platform may be supplanted by new consoles such as the recently released GameCube/Xbox, which technologically are far superior to the PS2. The console developers must then go through an awkward 32 Chapter 3: What Makes Game Development Hard? stage of trying to prove to the publishers that they are capable of developing on the new console platform. The only way to deal with these technological changes is to plan for them. You need to build profiling and diagnostic tools straight into your game so that you can understand how it is performing under various game conditions. You need to allow time in your schedule to support the odd piece of software or hardware that is strategically important to your publisher. You will also need to develop your minimum requirements as early in your schedule as possible. The sooner you set the goal of meeting a specific minimum requirement, the closer you will be to actually achieving that goal. The Art of War and Games Around 500 B.C. Sun Tzu Wu spelled out five essential points to follow for victory in battle: 1. He will win who knows when to fight and when not to fight. 2. He will win who knows how to handle both superior and inferior forces. 3. He will win whose army is animated by the same spirit throughout all the ranks. 4. He will win who, prepared himself, waits to take the enemy unprepared. 5. He will win who has military capacity and is not interfered with by his sovereign. “Victory lies in the knowledge of these five points.” Sun Tzu Only after writing the first draft of this chapter did I pick up my copy of The Art of War and flip through it. Notice how well this advice that is over 2,500 years old neatly describes the fundamental challenges of game development. Preproduction was so valued by Sun Tzu that he felt point #1 was insufficient and added point #4 with the admonishment of not hyping your game too early. Point #2 succinctly reminds you to create a game in response to the financial parameters of your game project. Point #3 clearly supports strong task visibility and a production plan signed off by the whole team. And I see point #5 as the combination of building your game development experience and not being forced to follow inefficient production methods due to inexperience on the part of the publisher. Sun Tzu’s five essential points in Chinese Chapter 4: Game Project Survival Test 33 Chapter 4 > > > > > > > > > > > > > > > > Game Project Survival Test This test is an adaptation of the software project survival test that can be found in Steve McConnell’s Software Project Survival Guide. The idea behind this test is to quickly get a rough guide to the overall preparedness of yourself and your team for the game project at hand. I suggest taking the test at the beginning, middle, and end of each of your projects as a reminder of good practices. The Game Project Survival Test As you read through the questions below, score 3 points if you are comfortable answering yes, score 2 points if you feel your team is partially addressing the question but more work could be done, and score 1 point if you really want to say yes, but it would be a lie. If the question is referring to something that occurs mid-project, answer the question according to your current plans. Game Requirements ___ 1. ___ 2. ___ 3. ___ 4. Has the core gameplay and user interface of the game been fleshed out so that everyone clearly understands what the game is and why it is fun? Do the team members think the game will be fun? ___ 5. Planning ___ 6. ___ 7. Does the game have a detailed, written game design document? Does the game have a detailed, written technical design document? Does the game have a detailed, written art production plan? Do you have a detailed, integrated project schedule that lists all of the tasks that need to be performed, and have the dependencies between various team members been indicated? Is there a clear, unambiguous vision statement for the game? ___ 8. Do all team members believe that this vision is realistic? ___ 9. Does the project have a reasonable expectation of being profitable for both the publisher and the developer? 34 Chapter 4: Game Project Survival Test ___ 10. Does your project schedule include tasks like press tours? E3? The Game Developers Conference? Installer? Autopatcher? Submission to hardware manufacturer approval? ___ 11. Were the schedule and the budget for the game officially updated and discussed between the publisher and the developer at the end of the latest milestone—even if to say, “Yes, everything is on track”? ___ 12. Are the features of the game tagged with core, secondary, and tertiary levels of priority to facilitate feature trimming if necessary to maintain the schedule? ___ 13. Does the game have a written quality assurance plan? Does it handle beta testers? In-house testing? Automated test suites? ___ 14. Does the game have a detailed milestone plan? Does it clearly describe what will be delivered and reviewable at each milestone? ___ 15. Does the schedule allow enough time for balance, tuning, and tweaking of features to ensure that it is fun? ___ 16. Does the schedule account for sick days, holidays, and vacation time? Are the developers tasked at less than 100 percent? Are the leads tasked at less than 75 or 50 percent depending on their responsibility sets? ___ 17. Has the game design, technical design, art production plan, QA plan, and all of the rest of the composite game development team signed off on the plan? Project Control ___ 18. Does the game have a single executive—the project leader or lead designer or producer? Whatever you call the job at your shop, has this person been given full authority, responsibility, and accountability for the success of this game? And is the person enthusiastically embracing this authority, responsibility, and accountability? ___ 19. Does this project leader have the right workload? Does she have the adequate amount of time to perform at her highest level of project management? ___ 20. Have the milestones been laid out with clear, measurable deliverables that can easily be quantified as done or not done? ___ 21. Are the milestones being delivered to the publisher in such a manner as to make it easy for them to review the milestones and measure the progress of the project for themselves? ___ 22. Do the developers have access to an anonymous communication channel where they can report problems without fear? ___ 23. Does the game project plan have a written plan for controlling feature creep in the game? ___ 24. Does the game project have a clearly defined method of how changes will be reviewed by development team leads such as the art and technical directors? Chapter 4: Game Project Survival Test 35 ___ 25. Are all of the game design, technical design, schedule, art production, QA, and all other planning materials easily accessible to all development team members? Are they encouraged to read the material? ___ 26. Is all source code under version control software? ___ 27. Are all of the binary assets such as textures, models, music files, and sound effects also stored under version control software? ___ 28. Do all of the team members have the tools to do the job such as workstations, PS2 and Xbox development kits, 3D Studio Max or Maya seats, bug tracking software, and scheduling software? Risk Management ___ 29. Does the game project have a written risks document with possible solutions? ___ 30. Is this risks document updated at the completion of every milestone? ___ 31. Does the game project have a risks officer who is encouraged to scout ahead for risks on the project? ___ 32. If the project is using subcontractors, is there a written plan for how to manage the subcontractors? For each subcontractor is there a single member of the development team who is responsible for that subcontractor? Personnel ___ 33. Does the game development team have all of the expertise needed to complete the game? ___ 34. Does the game development team have a management team that is experienced with managing game development? In other words, are the developers able to concentrate on developing rather than worrying about the state of their game development shop? ___ 35. Does the game have a lead programmer who is capable of leading the programmers of the team to making a kick-ass game? ___ 36. Are there enough developers to do all of the work? ___ 37. Do all of the development team members get along with each other? ___ 38. Is each team member committed to staying with the game until it successfully ships? Calculating Your Project’s Score ___ Subtotal: Add the points above (ranges from 38 to 114). ___ Development team size factor: If your game project has fewer than nine full-time developers, including all artists, programmers, designers, QA, and audio people, use 1.5. If your team has fewer than 19 full-time developers, use 1.2. ___ Grand total: Multiply your subtotal by the team size factor. 36 Chapter 4: Game Project Survival Test What Does My Score Mean? with unnecessary risk, frustration, and stress. Some degree of team burnout Scores: 102+ AAA—Your game has every possible resource, tool, and plan will occur. Anticipate some turnover at the end of the project. It is without it will take to make a hit game on time question that the project will be over and on budget. budget and will take considerably lonScores: 91-101 AA—Your game ger than planned at the start of the is being managed on a level much project. Anticipate cost overruns higher than the industry norm and is between 50 and 100 percent of the most likely to be a successful project with only a minor amount of difficulty in baseline planned. Scores below 45 C—Games with schedule or budget. Anticipate cost and these scores are at high risk of being schedule overruns of at most 5 to 10 cancelled by the publisher due to poor percent above baseline. progress visibility, feature creep, and Scores: 68-90 A—Your game is being managed better than the average cost overruns. Only a team without financial concerns will be able to plow game project. Significant challenges will pop up from time to time; however, through these challenges without being you stand a strong chance of mastering cancelled. These types of projects always result in developer burnout, and these challenges. Anticipate cost and some turnover will occur at the end of schedule overruns limited to 25 perthe project and to some degree in the cent above the baseline amount. middle of the project. These projects Scores: 45-67 B—This is about the typical level of management a game are advised to get serious planning and project is provided with. This game will management happening immediately or be cancelled and save the industry from certainly face significant challenges at one more crappy game. some point. The project will be run Part II > > > > > > > > > > > > > > > > How to Make a Game This page intentionally left blank TE Team-Fly® AM FL Y Chapter 5: What Is a Game Made Of? 39 Chapter 5 > > > > > > > > > > > > > > > > What Is a Game Made Of? The Extended Development Team Before you tear off into preproduction of your game, I want to show you all the parts that go into a game. Whether your background is art, programming, design, marketing, or sales, you will tend to view a game project as a medium of art, software with game design, a game design in motion, or a product to be marketed or sold. The big picture of game development involves a team effort of many individuals spanning dozens of professions all across our industry and spilling into other industries. When you see what it takes to make a modern commercial game, I hope you get a more balanced view of the various roles to be played to carry out a hit game. That Lever 2000 soap commercial is bouncing around my head right now with its silly jingle of all your 2,000 parts. So, following that jingle, let’s take a look at all of the parts of a game. Game Production Parts Surely a game project is all about producing a great game. If not for the developers, there would be no product to sell! I am biased as I am a developer, and so yes, I do think game development is the most critical component of a successful electronic entertainment product. However, the developers hold a sacred trust given to them by the rest of the project stakeholders that they will be able to develop a compelling and competitive game, on budget and on time. This is a sacred trust that has been violated more times than it has been honored. We developers must perform to the best of our ability to deliver the strongest game on time and on budget. Design Parts 1. 2. 3. 4. Lead Designers/Visionary Game Mechanics Level/Mission Designers Story and Dialogue Writers 40 Chapter 5: What Is a Game Made Of? The flavors of game designers of the team can readily use and is readily understood by the game’s publisher and other key stakeholders. The lead designer is not responsible for designing the whole game; rather it is the lead designer’s role to be a director and sculpt not only what goes into a game, but also what does not belong and should be cut. (In practice, the lead designer also picks up any design tasks that the rest of the team is not able to do.) How Do You Nail Down the Game Mechanics? Each game usually has a lead game mechanics designer. This person often We have to design a game first and has a game programming background, foremost. Some games have a key as programmers are the ones most visionary who has been kicking around likely to implement the game mechanan idea for a long time; others are more ics in the code. This person receives of a collaborative process with a leader. direction from the lead designer, solicits There is probably no single more diffiengineering feasibility from the procult task in the industry than being able gramming staff, and confers with the to create an original game of your own mission or level designers to find out design and see it through to commertheir requirements. Depending on the cial release (only a nitpicker would type of game, the game mechanics point out that seeing your game designer often plays with Excel, trying become a mega-hit would be harder). to achieve a rough balance to the game Each game has its own story of how it and simulating portions of the game to got to be funded and made. However, it get an idea of how some of their is usually the publisher or the studio mechanics will play both for single head of a successful game development player and multiplayer. company that has finally arranged for all the business points to be in place in Who Are the Level and Mission order to kick off their game. Designers? If the publisher suggests the game Some games have levels, others have concept, then the developer will supply missions, and quite a few have neither. the lead designer. Often the founder of Whatever game you have, it can almost a game development company will act always be broken down into a series of as a lead designer on the project. smaller challenges, puzzles, levels, or The lead designer’s job is to coormissions for the player to complete. dinate the design staff in the effort to Level and mission designers are somecreate timely, thorough, compelling times programmers writing scripting game design specifications that the rest code for a mission. Sometimes these Where Do Lead Designers Come From? Chapter 5: What Is a Game Made Of? 41 designers are artists laying out tiles of a map and designing triggers, and sometimes they work in pure text, describing to others how the game should be laid out. other than what the programmers and artists create. I am not trying to cast programmers as an uncooperative bunch; I am a programmer myself. What I am trying to say is that the programmers and artists are very special Story and Dialogue Writers Are people and often need to be convinced Writers for Interactivity of the designer’s vision. Most often the Writing a compelling narrative that is final implementation is a blend of the formatted for the high degree of designers’, programmers’, and artists’ interactivity found in games is a wholly collective vision. different skill than writing the narrative The programmers’ roles are to of a short story or novel or a motion obviously create the code: the 3D picture screenplay. A writer for games engine, the networking library, art needs to spend a lot of time with the asset converter, and such, to realize the lead designer for direction on where to vision for the game. Games are often take the story arc, and he or she needs late, over budget, or buggy as I mento spend even more time with the mis- tioned earlier. Games are hardly ever sion and story writers to determine late two months while they wait for the what is possible and not possible to do tile artist to get her act together, and in the scripting language, map editor, or games are hardly ever late by a month level building tool. because the audio guys have not masWriting natural sounding language tered your sounds yet. It is a rare for characters is not the same as just project that is delayed due to sheer listening to people talk and writing it asset production deficiencies, and even down; it is a talent for having an ear when that occurs the programmers are that sets the right rhythm of tone and not idle. Why? Because electronic balance for their characters to speak in games boil down to just code—code a fantasy world in a believable manner. with art, code with sound, code with I am discussing design roles that gameplay, yes, but it is still just code. people will play, not saying that each Even with code being the main deliverproject will literally divide its design able, why does it always have to be tasks into discrete people; in other late? This is an issue that is larger than words, designers will cross over back the game industry. In Steve and forth through these roles. McConnell’s Rapid Development, he writes that 50 to 90 percent of general Coding Parts software engineering projects are sigI detailed game designers first, as the nificantly late. Software engineering designers define the spirit of the game; projects, in general, are chronically failhowever, I have often been caught say- ing. The reason for this is that we game ing the ultimate designers on a project developers are part of a larger indusare the programmers and the artists. try—software development—that is in The designers can write documents and turn an immature branch of the engicreate specifications until they turn neering discipline. The processes in blue, but the game will not be anything specifying software, the processes for 42 Chapter 5: What Is a Game Made Of? creating software, and the processes for testing software and even establishing skill levels in programmers have yet to be established! You have to be a licensed engineer to pilot a ship for commercial transport, to build a bridge or a skyscraper, or even analyze the soil on a hill for a single-family dwelling. In fact, in California and in most states you must have a license to cut someone’s hair. No one needs a license to write code. The idea of licensing game programmers may seem, at first, ridiculously out of place in the game industry. The lifeblood, the very soul of the industry is founded on clever people dropping out of whatever they were doing before and putting their heart and soul into creating a fun game. Why do I advocate the clearly un-fun part of getting a license to write code? Imagine a future of game development where each game project has a licensed software engineer as the lead programmer or technical director (with the license administered much like a professional engineering license). With this type of person a very important safety structure has been put into place. Someone is responsible for the technical soundness of a project, and not only is her name and reputation on the line for this project, but her license to operate as a professional engineer could be revoked if she is shown to be manifestly negligent in her role as a technical director. I know I am way out on my own here with this opinion, but I really think this would protect not just the programming staff from unreasonable schedules, but the publishers themselves. They could lay down some outline of a feature set, quality level, budget, and timeline and say go make the game, but it would be so much stronger if they had to have the signature of the lead programmer (a licensed software engineer) to sign off on the project before the project could continue past preproduction and into production. Microsoft employs a version of this method where Microsoft employees have to sign off on a developer for technical, artistic, design, and project management competence before any funding of the team can commence. Well, enough of my diatribe on the merits of licensing programmers, let’s go see what they actually do on a project. Lead Programmers and Technical Directors The lead programmer has traditionally been the most experienced programmer on the team (from the 1970s through the 1980s, he or she could have been the only programmer). The lead programmer usually takes on the programming tasks that are the most challenging of the project. The quintessential examples of lead programmers are John Carmack of id and Tim Sweeney of Epic. These guys are usually the heroes of the projects, and many teams are structured around the lead programmer. Some games tend to have a large programming staff, such as the massively multiplayer game Ultima Online or EverQuest, or the single-player/ multiplayer game Neverwinter Nights with over 25 programmers. These large projects typically employ a technical director that oversees the programmers and reports directly to the project manager. The technical director title implies much less coding being Chapter 5: What Is a Game Made Of? 43 performed by the individual and more management of programmers and code creation. Sometimes smaller projects employ a technical director when the lead programmer is handling a tricky part of the project she does not care for or has no time for, or is otherwise not suitable for project management. Another model is to have a series of “assistant leads” who are all responsible for different aspects of a programming task—i.e., functional leads—who each in turn manage a few programmers and who ultimately report to the lead programmer. This is the model at BioWare and at Taldren. The lead programmer is like the queen in chess; she might be your most productive programmer on the project, but you must use her time wisely. Technical directors, on the other hand, act as scouts on behalf of the programming staff, looking ahead, lining up dependencies between programmers, and coordinating the development of the software. The rest of the programming positions I describe below are not necessarily distinct humans on every project; rather they are common programming roles that most projects have. A lot of projects, for example, have the 3D graphics programmer and the lead programmer be one and the same, or the game mechanics and user interface programmer could be the same person. Game Mechanics Programmer potions work, and how the protagonists and antagonists function. The game mechanics programmer can usually be seen near one of the project’s designers, debating the merits of the designer’s weapon mechanics and such. The game mechanics position is usually a mid-level programming job that ambitious scripters and mission programmers often grow into. The great thing about being the game mechanics programmer is you are the one who really puts the game into the game. You are the first one to see a lightning bolt strike the ogre, the first to see a tank shell a building, and the first to see the health pack heal the character. This is a fun job. 3D Graphics Programmer The 3D graphics programmer is one of the most highly respected positions in the industry. 3D graphics programmers must have a strong comfort level in mathematics including calculus, vector and matrix math, trigonometry, and algebra. The 3D graphics programmers enjoy seeing their work come vividly into being in lush 3D graphics, immersing the player in environments they can only dream about. Artificial Intelligence Programmer The game mechanics programmer is the one who converts the “real meat and potatoes” of the game design into playable code. This person usually models the physics of the game world, how objects such as weapons and The demands on the artificial intelligence programmer vary from game to game and from genre to genre. Steven Polge, now working with Epic, has written some truly impressive bits of AI code such as the Reaper bot. Also, the AI programmers are usually the folks who have the proper skills to write scripting languages and other tools used by the designers. 44 Chapter 5: What Is a Game Made Of? includes other mega-hits such as Half-Life, seems to say that every proThe user interface programmer is the person who has the tricky job of devel- grammer on the project should be a tools programmer half of the time. oping the software that bridges the Most teams do not have full-time game mechanics of the fantasy world tools programmers, although if the with a slick implementation of the user interface through the controls, in-game team is part of a larger house, there might be a tools department. Still, panels, and HUD elements, as well as the shell or navigational menus. The UI every solid game company builds up its own toolset over time to get graphics programmer is the expert on the UI on the screen, get audio out the speaklibrary and usually maintains it by extending its functionality. The UI pro- ers, and get the characters in the game grammer position is one that is likely to to have interesting behavior. A game development organization have been gained through experience in should have short-term and long-term the industry. UI programming is often tools production goals. I suggest a hard to get precisely right and is often Gantt chart produced in MS Project be underappreciated. printed out and hung on a wall to indiAudio Programmer cate the internal tools development in your organization. This visibility will The audio programmer is the person who codes up the 3D sound effects, the help everyone see how the tools are integral to the growth of your team and voice-over tag system, and the music playback system. Often this position is how things are planned to get better in the future. a light position due to strong, widely used audio libraries available such as Mission/Level Editor Programmer the Miles Sound System from RAD The mission editor programmer is just Tools. one of the tools positions; however, for Tools Programmer many games with a mission or level editor, the editor will be released to the Michael Abrash once told me that id public with the game’s release. spends greater than 50 percent of its programming resources creating tools. Developing a mission editor or level editor that is robust and easy to use is This is a significant statement. Most the work of creating another piece of game companies do not commit this level of programming resources to their commercial software. The UnrealEd level editor for the creation of Unreal games. BioWare has a large tools Tournament levels by Epic is a fine department as well, over ten people, example of a 3D solid constructive who make tools for all of BioWare’s games. They have found this saves a lot geometry modeling and scripting tool that is extremely powerful, robust, and of time and rework by designers and easy to use by both industry profesartists. The fact that id is arguably the sionals and by fans who want to make most successful developer ever, with many mega-hits of their own as well as new content for their favorite games. Some development houses organize a a prosperous licensing program that world-building tool as part of the main User Interface Programmer Chapter 5: What Is a Game Made Of? 45 game team, and others put this work in the tools group if they were rigorous in the technical design of the world editor to make it truly useful for other game projects. Network, Server, or Client Programmer? The network programmer writes the low-level and application-level code to get games running between a small number of players using modems, a local area network, or across the Internet. In the past the network programmer had to master a variety of protocols such as IPX, and serial and modem protocols. Modern games are now run almost exclusively on TCP/IP and UDP the networking protocols of , the Internet. The multiplayer architecture of games can be broken down into two main structures: peer-to-peer and client-server. Peer-to-peer structures have all of the player machines simulating their own copy of the game and use a variety of algorithms to keep the states on the different computers as close as possible. The peer-to-peer machines all talk directly to every other computer in the network. The bandwidth required to service this model of game grows exponentially with each added player. That is an unfortunate side effect as you try to handle more players. The client-server structure divides up the computing of game simulation into a server, which handles the actual simulation, and the client, which is the viewer, or browser, of the world events. There are several benefits to this structure, including the fact that the bandwidth requirement grows only linearly with the number of players, and the game can also be protected from quite a few forms of cheating by having it run on a trusted and secure server. (Remember, in a peer-to-peer game each machine is running its own copy of the world and has authority on some portion of the world. This authority can easily be abused by running a rogue version in the peer-to-peer network.) Why are not all games clientserver? Arguably they all should be; however, depending on the game, the client-server architecture is much more complex and requires divorcing the simulation and the presentation along much stricter object-oriented lines. Today’s massively multiplayer games are a prime example of the complexity of client-server games. Literally dozens of machines, running a score or more instances of servers, carry out different operations such as player authentication, version checking, cheat detection, game simulation, chat hosting, database transactions, and more. Peer-to-peer games are much more similar to traditional single-player games with the exception of the games periodically making corrections to be more in line with each other’s view of the world. Art Parts The artists of an electronic game may wear a host of different titles just like the programmers. Games used to have a single artist drawing the character sprites and the world backdrops for these electronic heroes to carry out their missions. In the earliest days the programmer, designer, and artist were one and the same person. Starting in the mid-’80s small teams of artists, usually no more than three, would work on a project. Starting in the early ’90s game projects grew substantially in 46 Chapter 5: What Is a Game Made Of? their art requirements and budgets. Famous examples of these are Wing Commander IV by Origin, where over $10 million was spent by Chris Roberts on chasing the dream of the fabled movie-in-a-game; Mario64, rumored to have a budget of over $20 million; and finally the Japanese epics in the Final Fantasy series and Shenmue, which have had gargantuan budgets. Artists are now differentiated by their skill sets. It is interesting to know that many artists can build 3D models of the most arcane objects quite accurately and swiftly without being able to sketch them. The domain of the artist now covers a wide enough area that you will need to plan your art team carefully to be sure you have enough bandwidth of skill and talent across your art requirements. and locations, and the game was off into production. Now with project budgets 10 and 20 times larger than in 1995, the stakes are much larger and the penalty for getting the art wrong is often fatal to a project. This is where the concept artist saves the day. High-quality black-and-white drawings are often colorized (color comp) to accurately convey to the art director, the producer, and the major project stakeholders what the look of an art asset will be before it is created. For example, on our Starfleet Command series, we needed to create a black-and-white sketch for each and every proposed ship model we wanted to introduce into our Star Trek game. These black-and-white sketches first made the rounds of the team to be sure we liked them, then the sketch went on to Interplay’s upper management, then on Art Director to Paramount’s interactive licensing The art director is the manager for the director, and on to even Rick Berman, art team, scouting ahead to be sure that the producer of the Star Trek television project dependencies are taken care of show and movies now at Paramount. Only when we received approval from ahead of time and that the artists proall these folks did we start to colorize duce their art assets on time for the the sketch and start the approval prorest of the game project. The other, arguably more important role is to look cess once again for the colorized sketch. Once this was approved, we at every art asset as it is being conwere permitted to actually begin work structed to be sure it is consistent in on an art asset that would make it into quality and theme with the rest of the the game. (The resulting 3D model game. would of course need to make this The art director job should be given to the artist with the most indus- same approval-seeking trip.) This approval process is even more try experience, tempered with people stringent at LucasArts on Star Wars skills, and the person who best enjoys properties, and Japanese games are the entire team’s respect. very much oriented around the concept Concept Artist artist, such as Yoshitaka, best known in the game industry for his work on the The concept artist is gathering visibilFinal Fantasy series. ity. In the past a few sketches would convey the look of the major characters Chapter 5: What Is a Game Made Of? 47 enough to get their 2D visions articulated into a painfully small set of pixels The 2D artist is an expert in classical using tools such as Deluxe Paint on the sketching and painting. These artists Amiga and later the PC. These artists are capable of painting backdrops, creon the whole were not prepared to hanating character portraits, and creating dle the technical requirements of tiles and sprites for use in non-3D operating a 3D modeling package. game engines. These artists used to Instead, a strange hybrid programuse Deluxe Paint in the golden age of mer-artist with a fascination for things game development and have now moved on to Photoshop, Illustrator, and 3D was required to operate the early arcane 3D packages. These artists were other packages. Even in a 3D game, the 2D artist is also in prime demand in the movie industry, and the scale of wages paid an incredibly versatile and important there made it very difficult for the game member of the team, producing highres artwork for ads and marketing, and companies to recruit them over to games. In these years game projects helping to create assets for a promohad to train their 2D Deluxe Paint arttional web site, install graphics, and ists slowly to use early versions of countless more elements of 2D art. LightWave and other technical 3D The interface designer usually is an expert 2D artist with a strong sense packages. Over time the packages got much of functional aesthetics. This artist will stronger and easier to use. College make just navigating your game’s menus an exciting and fun activity. The courses now teach 3D Studio Max, and interface designer is a key team mem- in general people have had time to learn how to use the 3D modeling packber; be sure you have one, or don’t make your game. Sometimes designers ages. 3D modelers are still highly respected members of any game team, and programmers with strong visual but it is more balanced now with the design skills can successfully fill this role. This area of art is the most closely other key art positions. tied to your game—the game design, Character Modeler the game mechanics, and the look of The character modeler is a specialized the game. And these areas see the most change of any art asset. For these breed of 3D modeler. Some strong 3D reasons, I strongly recommend against artists are competent at making mechanical things such as spaceships, outsourcing your interface design art tanks, and architecture, while others assets—get the best person you can seem to lean towards the organics of and work with him full time. characters. Low-poly character model3D Modeler ers have a special understanding of how the detail of the character will come to The 3D modeler was the highlight of life in the texture stage to make the the show around 1994-1997. At this most economical use of their polygon time artists with experience in the budget. industry were almost invariably 2D 2D Artist/Interface Designer artists who were clever or stubborn 48 Chapter 5: What Is a Game Made Of? framing and motion capture. Key framThe texture artist, like the concept art- ing is the older, more established method of animating your characters. ist, is now a highly visible element of Key framing excels at animating caryour art team. Games are almost toon characters and monsters and for always constructed out of polygons with textures on them. The sophistica- extreme movements—motions that are impossible to capture with a human tion of the modeling packages is so strong now, the texture phase of creat- actor. Animating by key framing is an entirely different skill set from 3D ing a 3D object is usually estimated at modeling, texturing, or sketching. If three to four times longer than the your project will involve characters that actual building of the model. The texture artist is a 2D artist who can “skin” need to be animated, be sure your team an object in his mind and create a com- has enough competent animators to get the job done; animation can be a slow pelling set of textures to “paint” that art. skin on the 3D model. Motion capture is the buzzword— Animator/Motion Capture Studio this is the state of the art. Humans Animation comes in two broadly differ- move with very subtle grace; studying a motion-captured movement will ent categories: character/animal/monreveal how much the whole body ster animation and everything else. Rotating antennas, windmills, and radar moves during the walk or the swing of dishes are good examples of the every- a bat. Motion capture’s largest drawback would have to be cost in both thing else category. Animating a windmill is an almost trivial task for an artist dollars and time spent massaging the on your team, while animating the snarl data into usable form. This field is conon a goblin’s face is an entirely different stantly improving, and there are half a dozen competitors in the field. In Chaptask. ter 33 I will show you in depth what JARGON: Key framing is the technique you need to know about motion capture of using a 3D modeling package to set including how to get a successful bid. key frames to have the engine interpoThere is quite a bit of technical late between. drudgery involved in smoothing out all JARGON: Motion capture is using a of the details of the character’s model special matrix camera to record the and animations—dealing with the skelmovements of a real human actor wear- eton, motion capture data, prop bones, ing a motion capture suit that has funny and a host of tiny, necessary details. reflective balls attached to it. Most proSome studios divide this work between jects that use motion capture also use the modelers and the animators key framing for part of their animation depending on the nature of the task, duties. and other studios like BioWare have To animate a character, two different dedicated folks called character riggers solutions are at your disposal: key who handle these types of tasks. Texture Artist TE AM FL Y Team-Fly® Chapter 5: What Is a Game Made Of? 49 when Origin’s Strike Commander was released for $50, but an additional If your game is to have any movies or speech pack was available for $20 more. cinematic sequences, it is important that your team have a storyboard artist. That is a testament to wacky product strategies as well as a testament to the The storyboard artist will be able to compelling depth voice adds to a game. design and articulate the scenes in a The only way to get good voice sequence for internal and external work done is to work with an experireview before committing to costly live action or resource-intensive computer- enced voice-over director. A good generated sequences. Show the movies director will know immediately where to secure the talent, the studio time, to the publisher, show them to the and the engineer, and get you the postteam, and work it all out ahead of time processed audio in a format you need. through simple boxes and captions. In Chapter 29 I will guide you through Most storyboarders are accomplished the process of getting high-quality concept artists but not necessarily. voice into your game. The pleasant surAudio Parts prise of voice work is that it is probably the coolest element you can add to your Audio assets come in three main flagame for the money, and it is essential vors: sound effects, music, and voicein many role-playing games, which are over. In the beginning there were only crude sound effects performing buzzes, dialog and VO intensive. beeps, and whistles. We now have full Sound Effects Dolby 5.1 3D sound. Music has come a long way from clever timing of beeps to Sound effect engineers are wizards at listening to one sound and finding compositions by film composers performed by 50-piece live orchestras. And clever ways to stretch it, compress it, twist it, and come up with precisely the voice acting is now an art form persound you need. Sometimes they will formed by stars like Patrick Stewart Foley—that is, record your sound effect and contracted under the authority of from the actual object generating the the Screen Actors Guild. sound. Sometimes the sound engineer Voice-Overs will record some other sound and then twist it around just for your game. Voices in a game really bring it to life. Sound effects are an excellent tarCompelling voice acting reinforces get for outsourcing as only the larger every other element of interactivity developers with three or more concurby having the actors speak to your rent projects can keep a sound effects character. The tutorials for Starfleet Command went from being a dry intro- crew productively working. Chapter 30 contains an interview with a sound duction to our gameplay to being the engineer so you can see what it will most compelling Star Trek moment I take to get strong sounds into your ever experienced with George Takei game. performing Admiral Sulu teaching me Storyboarder to command a starship. I remember 50 Chapter 5: What Is a Game Made Of? every team member will be compromised by a little distraction at a time. Some games spend a lot of effort on The line producer will often supply the music, and it really gets the emotional hooks into the player when the music is team with food when the hours are forced and late; will get design docufirst-rate. Music is probably the most popular and oldest art form worldwide. ments printed and sent overnight; and will often coordinate getting builds out Nearly any emotion can be invoked to the publisher and to beta testers. with compelling music. There are two The line is a critical function that options: synthesized music and music that is performed live. We spent nearly should be filled by a line producer, instead of your art director on Mon$100,000 on the score and 30-piece days, your 3D graphics programmer on orchestra performance for Starfleet Tuesdays, and so on. Command 2. The music was very special; all of the sounds are richer and JARGON: Builds and revs refer to interim functional versions of the game fuller bodied when performed by distributed for testing to internal and humans versus a synthesized chip. external testers. That being said, a single musician can create extremely strong music with a Associate Producer professional synthesizer and software. The associate producer is found on Chapter 28 will discuss outsourcing larger projects in a single team commusic in detail and give you plenty of pany, and all ompanies with multiple leads to be sure your game has the emotional impact of high-quality music. teams need an associate producer. Publishers also structure themselves with Management Parts an executive producer managing a group of titles and an associate proManagement of a game project is the ducer on each title performing day-tomost critical component in my experience. In recent private email with other day management. The associate producers have an interesting combination studio heads in the industry, the conof a lot of responsibility and little sensus was that a developer is limited authority. The associate producer is the in number of teams not by programunderstudy of the executive producer. mers or artists, but by quality producThe business negotiations, contracting, ers/project managers. That being said, and human resource decisions will be the management of a game project is carried out by the executive producer, often shared by a group of individuals but in almost every other aspect of the with different responsibility sets. game project the associate producer Line Producer will have a strong contribution to make. The associate producers are often burThe line producer coordinates countless small tasks that one by one are not dened with the dreary task of updating the schedule and reporting on task very challenging, but taken as a whole tracking. The associate also helps comis a daunting amount of work that needs to get done every day. If a project munication between all team members and is usually the strongest advocate lacks a line producer, the efficacy of Music Chapter 5: What Is a Game Made Of? 51 for the game. In truth, each studio has its own name for the hierarchy of managers in the organization such as assistant producers, senior group producers, and project planners. Studio Head/Executive Producer The studio head at a game developer and the executive producer at the publisher each have the same fundamental job on a game project: be responsible for planning and executing the project in a profit-producing manner. Studio heads are almost always the founders of their own companies, those who have risen through the ranks and are industry veterans and who have paid their dues and made money for their publishers in the past. In the case of Valve, Gabe Newell brought lots of project management experience from 13 years of creating software such as Microsoft Windows. Studio heads run small companies—game development shops—and have to simultaneously be game designers who are passionate about their games, software managers who respect technology, and businessmen who are savvy enough to get a good publishing deal. Some developers such as id and Epic have divided the role of the studio head into a more practical split of one person running the business and another acting as the project leader for the game. The business development executive at the publisher often supplies the executive producer on the publishing side with a game project and game developer lead. The executive producer’s job is to then complete the evaluation of the developer and project to determine its suitability for production. If the executive producer is confident the project should go forward, he will negotiate the key terms with the developer and work to help the project meet its first internal green-light or assessment milestone. If the project passes, then the executive producer’s job is to oversee the project’s progress through the reports generated by the associate producers and by looking over builds of the project in progress. The executive producer is often called upon to maintain the relationship with any licenses and is sometimes involved in contracting external vendors. The executive producer is the person most visible inside the publishing company for the game’s success, while the press and the fans tend to focus on the game developer. Producer As a game development studio grows into two teams or larger, the role of the producer becomes critical to the effective execution of the studio’s projects. The producer is the person who will manage the project at a larger development studio, allowing the studio head/executive producer to concentrate on strategic company issues. 52 Chapter 5: What Is a Game Made Of? Quality Assurance Parts Quality assurance (QA) is another critical component of game development. The single best way to test your game is of course to play it and play it until it is solid and as much fun as you know how to make it. The problem with this method is that it will take a very long time for a single person to play through a game in its entirety (which may not even be possible), and a single person will make errors and have a bias. The industry has yet to come up with a unified testing method that is known as the best practice employed widely. Instead each developer and publisher and indeed each game project tends to have its own QA process. Microsoft appears to be the organization that exerts the most effort in a rigorous QA process. Most small developers do not have a full-time QA staff, as they would only see useful work roughly half of a project’s lifetime. Larger, multiteam development companies can often gainfully employ a full-time QA staff. For example, BioWare employs a full-time QA department of over ten people, which supplements the even larger QA teams at their publishers, reducing the errors sent to the publishers to speed up development and saving the developers themselves from having to test their own stuff, instead allowing them to focus on finishing new content/features. Smaller developers often cross-train the line producer and associate producer to be the first line of QA with a backup of team-wide testing days. Publisher QA Parts All high-profile commercial games receive a considerable amount of professional testing by the publisher’s internal QA department. This department follows the guidelines set by the publisher’s management and works as efficiently as possible to report defects in content and quality to the developer prior to commercial release. Most commercially released games have anticipated release dates that are difficult to postpone in the case of a late project or a particularly buggy one. These internal QA teams are trained to report the severity of the defect and generally create high-quality bug reports that have items prioritized for the development team’s attention. QA Lead The QA lead is the person who leads the efforts of the QA staff. The QA lead is always a former tester who showed promise of superior skill in organization and communication. The QA lead coordinates getting new builds or revs of the game in progress. The QA lead also proofreads all reported defects from her team and discards duplicate and erroneous reports and often rejects reports back to the reporting tester, requesting clarification and/or testing. The QA lead is almost always an aspiring game designer or producer and often includes extensive commentary on the game’s content in order to gain visibility for possible promotion. This is because most publishers have an outdated, poor concept Chapter 5: What Is a Game Made Of? 53 of the QA staff and treat them as lowskilled, low-paid workers, leaving those workers with little choice for a career in QA. Instead they are actively trying to strike out into development or some other role in the game industry. A notable exception to this is Microsoft, which seeks out folks with college degrees and pays well for its QA positions. multiplayer team and main team are specialists in a particular portion of the game such as a chapter or character class or playable race. Fresh Teams The problem with having dedicated main teams and multiplayer teams who look at the same game from three months to a year is that their ability to discern fundamental problems with Main Team gameplay and usability are comproThe main QA team is the team that will mised fairly quickly as they learn the monitor the game’s progress from the game and lose the critical insight of a time the game is initially submitted to new player. It is still important to have QA through release and often into efficient teams who know what the post-release. The main QA team will go game is and what the last reported set through stages of varying productivity of bugs were so they can quickly turn in direct relation to the development around a bug report to the development team’s ability to respond to the bug team. However, fresh teams are often reports in a timely fashion. This team is introduced to a game the closer it generally referred to as the QA team comes to shipping, depending on QA even though there are many other resources available internally to the potential testers of the game. The main publisher. QA team will often rotate in fresh team Compatibility Team members as a natural process of other games finishing and employee turnover. The compatibility team is often a dedicated team of QA members who happily Multiplayer Team rebuild computers all day while testing Games with significant multiplayer the major functionality of your game. gameplay often have a QA team dediThese guys have very little work to do cated to testing this functionality. This on a console! The compatibility team is more common with PC games, as usually has a standardized checklist of console games tend to have much more hardware and operating systems the limited multiplayer gameplay. The publisher considers commercially multiplayer team is used to be sure all important to support. of the modem, LAN, Internet, and matching options are thoroughly tested. Localization Team Bugs associated with multiplayer code Also, all big games are localized into are often more difficult to track down various markets, and native speakers of and report; this allows testing of the these languages will be employed to single-player campaigns and missions QA both the accuracy and the quality of to continue on in parallel. In the same the localization of the game. manner, individual members of both the 54 Chapter 5: What Is a Game Made Of? Beta Testing limited rigor employed to date on beta testing programs still results in the Beta testing is testing performed by pressure to release these games to the unpaid volunteer fans who want a first public and endure two to six months of peek at an upcoming title and who are excited by the opportunity to improve a painful post-release beta testing that strains the faith of your hardcore, game before its release. At first many early-adopting fans. publishers were apprehensive that a beta version of the game would become Beta Testers widely pirated and steal sales from the The beta testers are almost always the release version of the game. Or in the fans who showed up on your message case of weaker titles, many publishers board when you first opened up shop. consider it a shrewd strategy to avoid They often have beta testing experithe beta testing stage. Perhaps the most successful beta testing programs ence or have heard about beta programs and will sometimes be quite are run by id; examples of these are proactive in their effort to secure a seat Doom and Quake Test. These firstin your beta testing program. The numperson shooters had multiplayer ber one rule with beta testers is to gameplay and no single-player missions. Even with only three or so maps communicate with them; failure to do so only creates an expectation in the to play test, these “tests” by id produced more hours of fun and gameplay beta tester’s heart that they are part of the development team, only to find out than most games ever achieve in their that their voices are unheard. final release. I personally played several hundred hours of Quake Test Beta Testing Program Manager before Quake was released—sniff— To facilitate this communication with thank you, id! Bottom line, if you want to make a the beta testers, one of the developgreat game, run a beta test and fix your ment team members—often the game until beta testing proves you are associate or line producer—takes on the role of beta testing program manready for release. In recent years the ager. This is a very stressful job. The advent of the massively multiplayer game has required extensive beta test- time period that beta testing takes place is during the final months of a ing. These massively multiplayer project when everything must come games require hundreds if not thoutogether. The beta testers are anxious sands of concurrent players to analyze to see their reported defects fixed in how the server will respond to the the very next version of the game and stresses of full release. These thouare quite vocal about new features they sands of beta testers are also required want and how they want the game to be to smooth out the authentication, balanced. In Chapter 23 I will discuss account management, and game balance to avoid having paying subscribers the mechanisms and techniques the beta testing program director should complete the beta testing period. The employ for a successful beta test. sheer costs of these games and the Chapter 5: What Is a Game Made Of? 55 Business Parts Making games is big business. Depending on how you look at the numbers, the console game market (hardware and software) along with the PC game market generates more revenue than the box-office receipts of all of Hollywood’s films annually. There are a lot of different business executives who are involved in a game project; here I will present the major roles. though). Making sure that your game is visible and impressive to this key executive at green-light meetings ensures the highest level of support the organization can bring to bear for your game. Studio Heads Founders, lead programmers, visionaries, game makers, CEOs, presidents, head coaches—whatever you call them, studio heads are the chief decision makers at a game development house. Business Development Parts Studio heads generally have five to fifteen years of experience in the game Business Development Executive industry and at least one hit title under The business development executive is their belt where they held a strong lead casually called the “biz dev.” role. Studio heads most commonly come from programming and design JARGON: “Biz dev” is the short name given to the business development backgrounds, although there are some executive at a publishing company. medical doctors of considerable renown running BioWare. Artists are the majorWhen developers go around pitching games to publishers, they first need to ity shareowner at id, and Gabe Newell get the approval of the publisher’s busi- of Valve had an extensive background of ness development executive before the software development at Microsoft. Studio heads decide the fundamengame is sent to a green-light tal structure and working environment committee. for their studios based on past experiThe biz dev person keeps a close eye on what is going on in the industry ence. The studio head is intimately and is the first to know about games in involved when a game project is startdevelopment that are looking for a pub- ing up and is usually the salesperson pitching the game to the publishers. lishing deal. The biz dev person often Studio heads are generally the most negotiates the key terms of a game qualified team leaders in their organizapublishing contract. tion and spend a lot of their time Publisher CEO and President training new producers to run teams and subteams. A chief executive is responsible for all aspects of the game publishing corpora- Lawyers tion. Very often this individual has ten Both the publisher and the developer to twenty years in the game industry need the best lawyers they can afford. and has a well-developed instinct for Each contract is unique, and while a making great games (not infallible 56 Chapter 5: What Is a Game Made Of? publisher’s contract is the fruit of many painful relationships, the developer should be patient and exercise great care in negotiating terms. This is something you do not want to try on your own. WARNING: Do not negotiate a publishing contract without the aid of a lawyer who has strong experience in electronic entertainment publishing contracts. the title appears to be, the wholesale price, and the influence of any number of incentive programs that have been negotiated between the publisher’s sales force and the retailer’s buying force well before the game’s release. Sales Executive Lawyers are actually good people who help you understand clearly what a contract is and is not saying. Understanding what you are agreeing to before you sign a contract is a fundamental safety mechanism for both the developer and the publisher. In Chapter 27 I provide a list of law firms who are used by different studios. Licensing Parts Many games are based on licenses such as comic books, novels, movies, and sports stars. In turn, games themselves are licensed to create strategy guides, action figures, T-shirts, and movies. Publishers may have their biz dev executive manage the licensing of a game, or they may have a full-time staff member for routine licenses such as strategy guides. Promoting, Buying, and Selling Parts Sales? Is that not the job of the teenage clerk at the local Electronics Boutique? Well, yes of course, but well before a gamer walks into a computer game store, a sales force has made the larger sale of the game to the buyer agent of the retailer. The decision on the retail buyer’s part of how many units of the game title to order on release depends on how hot Each publisher has a top executive in charge of sales. This person has a lot of influence on the ultimate sales of a game. The executive in charge of sales has a budget that goes by several different euphemistic phrases such as “marketing development funds”; this budget is spent to buy shelf space at retail. This is a pretty strange concept to people who are unfamiliar with the industry—that the publisher not only needs to absorb the risk of funding the development of the game and its packaging and marketing, but also must completely absolve the retailer from any risk. Selling games is a consignment business. The retailer will put the product up on the shelves, and if it does not sell quickly enough, the retailer simply sends the product back and gets its money back. Retailers take maximum advantage of this relationship when a highly anticipated game is released by ordering as many units as the publisher will deliver. It sounds great when you have an order of 200,000 units from CompUSA for your game, but if your game fails to meet expectations, CompUSA will not hesitate a moment to send 160,000 units back to you—all marked up with their price tags—and simply order more later. Those 40,000 units you sold at CompUSA effectively had the packaging and shipping costs of 200,000 units, which wipes out much of Chapter 5: What Is a Game Made Of? 57 the margin from those 40,000 units that did sell. A careful study of some publishers’ financial reports to the SEC will show periodic “write-offs” and “one-time charges.” There can be a whole variety of reasons why a business is forced to report a loss on their books, but in the case of game publishers it is often massive quantities of returned games that they have accumulated for as many quarters as they could get away with. It is not unheard of to see six to ten quarters of accumulated returned product discharged as a write-off. Keep in mind that during those six to ten quarters this product was accounted for as revenue. This practice is not sustainable, and the stronger publishers do not do this. A strong sales executive should work closely with the publisher’s chief financial officer to manage what is called “sell-in” to the retailers with the goal of having the highest “sellthrough” to “sell-in” ratio. JARGON: Sell-in is the number of units the retailers order or buy. Sell-through is the good stuff; this is the measure of how many units of your game were sold through to consumers —a true sale. and Klingon impersonators to get the sales staff pumped up and primed to handle the buying agents. Press Relations Manager The press relations manager will oversee how the game is communicated to the press. For large titles, this is a nearly full-time job, and a quality PR manager should be split across as few titles as possible—one to three titles at most. The PR manager will field all press inquiries, as well as inquiries by those claiming to be press. The PR manager will strategize and plan how the details of your game will be released to the press. JARGON: Buzz—what the press, fans, and industry are saying about a particular title. Sales Force and Retail Purchasing Agents Under the direction of the sales executive, the publisher’s sales staff meets periodically with the retail purchasing agents, each of whom represents a different retail chain. Prior to calling on the buying agents, a publisher will often host an internal sales meeting to communicate their product’s selling points to the sales force. These meetings can sometimes be fairly lavish with, for example, large ice sculptures If PR has a solid date on when the game will ship, then PR can create a solid plan for ramping up the buzz in a steady, ever-increasing volume to peak just as the title is released. Releasing too many of your game’s goodies too early will provide you with little to say later in the project, and interest in your title will sputter and fade before it is released. On the other hand, if you do not release enough information on your game to grab press and fan attention, it may be difficult to maintain the support of the executives at the publisher and other project stakeholders. Trade Shows The Electronic Entertainment Expo, or E3, is the largest show in North America for publishers to get their products implanted in the agents’ minds. E3 is a vast show with tens of thousands of attendees strolling through hundreds of displays ranging from mini amusement 58 Chapter 5: What Is a Game Made Of? parks from the likes of Nintendo to a folding desk and some business cards from discount CD duplicators. Thousands of products will be on display and scores of tricks are used to try to get your attention, from the obligatory booth babes to breath mints that are rolled out like cellophane. E3 is a cacophony of sound effects, lights, noise, and people. For all of this energy E3 is the largest news reporting event in the game industry and next to the retail buyers, the game press is the second most important contingent of VIPs to grace the floor. These folks have conspicuous press ribbons dangling from their badge so you know when not to speak candidly (handy). Like anything competitive, the press at E3 is out to get more viewers and readers. The larger the market share, the more their business will grow. Years ago the press were trying to figure out how to arrange their time more efficiently for those precious three days of E3; they wanted to be sure they looked at every hot game. It would be a minor tragedy if a competing magazine or site were to report on a major title that you failed to see at the show. So the publishers and the press put together a schedule of viewings and demonstrations for all of the large press. That might sound innocent enough, but if you think about it for a moment, you will realize that all of the major press walks into the show with a schedule of titles filling all of the required genres and platforms prioritized in order of importance. Of course this journalist will still walk the floor, but it will be between appointments or at the end of the show. This makes it really tough for the little games trying to break out, as they are not even on the list to be seen. The Internet game sites have another pressure—real-time reporting. To keep up, all of the major game sites need to have nearly live coverage of the show in an effort to bring the show to the fans and of course to gain more viewers. Real-time reporting is hard for several reasons, not the least of which is that you need to have something to say. Here again, publishers and the press will work together to give the press an E3 package a couple of weeks before the show. This package always contains the best screen shots, plenty of quotable material, and occasionally a playable preview build of the game. The better journalists look at this material as just more information; the less rigorous journalists (or those with very little time) have been known to lift the majority of the quotable material and publish that in lieu of an original opinion on the game. Other Trade Shows and Events TE AM FL Y Team-Fly® E3 is important and dominant no doubt; however, it is hard to get your message across to the buyers, press, and fans when there are 3,000 other titles. Publishers have been creative about how to handle this problem; they hold their own shows in one form or another. For example, Activision hosts its own show in Europe between E3 and ECTS (the major show in Europe) to be sure awareness is implanted before and more effectively than the ECTS show. Interplay hosted a very cool event for three of the Star Trek games (one of which was Starfleet Command) on the Paramount Studios lot. Press from around the world came to view three Chapter 5: What Is a Game Made Of? 59 games hosted by George Takei. The trailers for all three games were shown in the posh Paramount screening theater, and a fine lunch was served where the press mingled with the developers for an extended Q&A period after the press had a couple of hours to play the games. It was a relaxed but focused event that gave those three games ample time with the press. The Marketing of a Game coordinate strongly with the press manager and sometimes supervises the press activities. Sometimes it is considered a peer position, and in some places the same person is overloaded with both jobs. In particular, the marketing and press managers will be working closely with any playable demos that are to be released, making sure they are cover-mounted on the game magazine CDs and that the retail stores carry a supply of demos in a display. Hardcore Fans As you can see there is a lot of sales and promoting of a game behind the curtains, but what about the ads—the traditional form of selling a product? Of course games have ads; take a look at your favorite game magazine and it seems like half of the pages are fullpage ads. And the online sites have banners, navigational bar headings, and a myriad of advertising terms for the various bits of electronic click-mes. Like the press relations manager, the marketing director for a game should not be spread too thin across many different games. The marketing manager will work with the producer and development team to craft the game’s image in all of its various forms: print ads, banner ads, and the all-important box. Just like press coverage, it is important not to create too much hype for the game and then fail to deliver on time. Publishers are getting much more savvy and are scheduling their marketing campaigns to kick off only when the ship date is known with confidence. The marketing manager will also be responsible for getting your game shown at smaller venues such as the GenCon game convention held in Milwaukee. The marketing manager will It is commonly known that hardcore fans and the word-of-mouth sales they generate is the largest factor in the number of games you will sell. Hardcore fans are eager to check up on the progress of their favorite game at the developer’s web site, interact in the forums, and beta test. If they like the game, they can be responsible for not just the sale of the box they buy for themselves, but for the six or eight boxes that they have convinced their LAN party to play with. Or in the case of console games, the hardcore early adopters get the game first and invite people over to play. I have met fans who have sold ten, twenty, and more titles just for their passion of the game. Hardcore fans are always looking for the best in games; they also have a bunch of friends the industry calls casual gamers and mass-market gamers. These casual and mass-market gamers ask for recommendations from the hardcore gamers. The hardcore gamers will in turn recommend the titles they feel comfortable with. This is just common sense, but what it means is that Blizzard’s Diablo was perfectly poised to capitalize on the 60 Chapter 5: What Is a Game Made Of? streamlined interpretation of the computer role-playing game genre where just light taps on the left mouse button looted catacombs and vanquished elemental evil. Valve’s Half-Life laid a heavy story on top of the first-person shooter genre dominated by id (in fact they licensed id’s Quake engine) to produce a mega-hit. And depending on how you measure it, Half-Life and its free, fan-created mods Counter-Strike and Day of Defeat are the most popular online games. These games are simply the most approachable, solid, and just plain fun games you can buy. If you want your game to sell, study how narrow the feature sets of Mario64, Half-Life, and Diablo really are, and how well and deep these few features are executed. until all features have been frozen and all stats in the game have been balanced. This results in almost all manuals being vague in some areas and fairly narrow in the scope of just providing use of the controls of the game, rather than how to play the game. Now enters the strategy guide. Strategy Guide The strategy guide fills a niche role in the game industry, providing detailed stats, walk-throughs, strategy, and tactics to complete a game. Writers of strategy guides have various stories, but it is not as simple a job as playing your favorite game and writing up all the nifty hints and secrets. What really happens is that the publisher of the game and the publisher of the guide work together to get builds of the game Manuals and Strategy Guides to the strategy guide author as early as Games need to have a manual, and if practical in the project. Essentially, the the game is considered a potential hit, guide author is a beta tester too; this then no doubt a strategy guide will be makes the job of writing the definitive produced for the title. guide more challenging as the stats, missions, puzzles, and various parts of Manual the game are still in flux. For instance, How the manual gets written varies even the ultra-high-profile game Gran from publisher to publisher and from Turismo 3 (GT3) for the PS2 contains game to game. The most common many discrepancies in the pricing of method is to use an experienced convarious upgrades between the U.S. vertract manual writer. This person sion of the game and the U.S. strategy receives a copy of the game about four guide. GT3 shipped in Japan well ahead to six months before release and inter- of the U.S. version and as such there acts with a member of the development was a little more time to produce an team while writing to create the most accurate guide. Despite this there were accurate manual possible before a game still discrepancies. ships. Another common method is for For our own Starfleet Command: developers to create the manual given Orion Pirates, the strategy guide writer that they are the most familiar with the of SFC2, Dennis Green, returned to game’s functionality. The biggest chal- write the most thorough guide possible. lenge in creating a manual is that rarely His project came under stress when we does one have the luxury of waiting at Taldren overlooked some of his Chapter 5: What Is a Game Made Of? 61 requests for information during the final push. Unfortunately, after we were able to catch up and provide him with the information he needed, several strong chapters of the book had to be cut to reduce paper costs for the guide. It is a tough market to make money when work already created has to be cut. Manufacturing Parts I am astonished at how quickly a PC game can reach the store shelves. Do you know how fast a publisher can take the final gold master from the hands of the QA lead and deliver a shrinkwrapped retail box in an Electronics Boutique shop in the local mall? Five days. That is right, in five days a 30-cent recordable CD from the local OfficeMax can be turned into $70 million of merchandise on store shelves in the form of Diablo II. This is perhaps the quickest a game can reach the store shelves and usually only occurs at a fiscal quarter end for the publisher—most especially Q4 for the holiday shopping season! To accomplish this a publisher has an operations manager who keeps his eyes peeled looking for the strongest vendors for CD duplication, manual printing, box printing, and assembly. This is quite a job, and normally they would like to see about 20 to 30 days to get the job done, so as to not have to pay for express drop shipments between the vendors. But when the end of the quarter is rearing its ugly face, the operations manager saves the day. Toward the two-thirds mark of your schedule, meet with the operations manager to nail down the firm dates for when they need everything—final box, final manual, and final posters and other goodies in the box. This is definitely an area of the project where it repays you in spades to be proactive and find out the due dates for these deliverables ahead of time. Hardware Manufacturer Parts Console Manufacturers The console manufacturers assign a producer to oversee the development of each of the titles for the platform. The console manufacturer retains broad editorial approval rights for the game, and it is very important to follow their feedback to receive your ultimate approval for the gold master. Hardware Representatives Some of the coolest people to work with in the industry are the hardware vendors like SoundBlaster and NVIDIA. These folks are motivated to be sure that not only does your game work on their hardware but also that your game takes advantage of all of the features of their latest cards. What that means to a PC developer is a bunch of free hardware such as sound cards, video cards, joysticks, and speakers for use of the development team to test the hardware. These folks are best approached at their booths at the Game Developers Conference (www.gdconf.com). Tell them your story, where you are working, and what game you are working on, and if they feel that you are for real, you can get test hardware. Please do not abuse this if you are not making a commercial game and will not be making a genuine test of the hardware, as it will only make those resources harder to come by for the rest of us. 62 Chapter 5: What Is a Game Made Of? Post-Release Parts Releasing a successful game to retail will be one of the most difficult things you accomplish in your professional career. After all of the cleverness it will take to get your project funded, staffed, and real; after all of the dedication to the craft during production; and after all of the blood, sweat, and tears it will take to drive a game through the final candidate cycle, you will find the day after you signed off on the gold master one of the most pure days in your career with no task that must be done now. Instead, you and the rest of the team will most likely disappear and rediscover what your family looks like and decide to talk with them—and sleep. After this much-needed rest is completed, is it time to dream up a new game? No, it is time for post-release. Post-release involves patches, updates, answering questions on the forums, helping customer service field questions on the phone support lines, and combating cheating. For massively multiplayer games, these issues are much more serious as you are billing for a monthly service instead of a one-time purchase of a product. In fact massively multiplayer games have whole development teams called the “live teams” to maintain the software, add new content, act as gamemasters, and in general keep the product fresh and alive in the hands of gamers. Having a bunch of fans is a very good thing; that is the whole reason for your work. However, a bunch of fans require a substantial amount of interaction and communication. At Taldren about six of the employees have taken the initiative to read our forums on a regular basis to field questions and moderate the forums. Chapter 24 discusses the issues of post-release in detail with guidance from several studios on how to most effectively support the fans of your game. Chapter 5: What Is a Game Made Of? 63 This page intentionally left blank Chapter 6: Business Context First 65 Chapter 6 > > > > > > > > > > > > > > > > Business Context First The first project sin that people commit is to dive right in and start designing their game, or worse, to start programming. Every project, from the largest massively multiplayer games with development budgets over $8 million to total conversions done by some hardcore fans, needs to be positioned within an appropriate business context. Even if you have no plan to make money off the game, or it is not a business venture, it is still critically important to identify why you are making the game and what the goals are for your game. The Project Triangle A useful device for analyzing the goals of your project is to create a triangle and label the points of the triangle as follows: (1) On Budget, (2) On Time, and (3) High-Quality/Feature Rich. It is a business law of software development projects (and just about any other type of project) that you can achieve two out of three of these goals on any project, but you cannot achieve all three. Failure to understand that you can only have two out of three of these properties will result in a game that misses not just one goal, but also two or three Where the business parameters lie on the project life cycle 66 Chapter 6: Business Context First of these goals! See the diagram below for a visual aid to this example: n n n On Budget and On Time—means you must accept sacrifice of quality High Quality and On Budget— means you must accept a late game High Quality and On Time—means you must accept extra spending The Project Triangle—pick two out of three goals Implications of the Project Triangle Each line on the triangle is a relationship between two of the goals. Each line should be responsibly labeled with the negative consequence of your decision. This triangle states that every well-managed project will exhibit one of three negative behaviors: being late, being over budget, or sacrificing quality. This sounds pessimistic, but it is true. Once again for impact: Well-managed projects will be late, cost too much, or be of low quality; less well-managed projects will exhibit two negatives; poorly managed projects will feature all three failures. There are many different software development strategies on the market such as Iterative, Waterfall, Extreme, Unified, and others. None of these development methodologies are a magic potion. You will still be faced with the question of how to best manage your particular project and its challenges. Instead, each of these methodologies will have strategies and suggestions for managing costs, time, and features. However, it will come down to the business context of the game and how you manage your project to decide which two goals you will meet and which one you work to control and manage. A project where being on budget and on time is more important than quality A project where being on budget and having high quality is more important than timeliness A project where being on time and having high quality is more important than cost Chapter 6: Business Context First 67 Various Games and the Project Triangle only one goal instead of two goals? The Sims met a huge unfulfilled demand to play god to simulated people doing ordi1. The Sims series: High Quality 2. Diablo series: High Quality and On nary things; this has enormous appeal to consumers and gamers of all ages, Budget 3. Quake series: High Quality and On especially women. The designers of The Sims knew that above all they had Budget 4. Ultima Online series: High Quality to get the simulation right. If The Sims was boring or lame, people would be 5. Starfleet Command series: On turned off and not play. So they crafted Budget and On Time 6. Baldur’s Gate: High Quality and On and crafted the behavior of The Sims almost to exclusion of any other feaBudget tures, considering the relatively mod7. Klingon Academy: no goals satisest effort spent on the graphics. No one factorily achieved had modeled people before quite like this, and in the early days of the project there was only modest support for it, as other games at Electronic Arts were given more resources. Thus the designers of The Sims did the right thing and recognized the business parameters of their project and focused on what would really matter—the behavior in The Sims. Sure, if they’d had stronger corporate backing early on, they could have staffed up and perhaps sped up the research and development phase to under a year and then just another year to create the whole game. This would have been ultimately more lucrative for Electronic Arts, as they would have made this ungodly amount of money earlier and would Various games and where they fit on the Project have had made the team available to do Triangle the expansions to The Sims that much quicker. Looking back at game projects How is the triangle related to success? from afar, it is easy to be an armchair The Sims is probably the highest gross- executive producer and say what you ing PC game in history, being at #1 in would have done better, but truthfully the charts for close to two years punc- in the early developmental stages of tuated by a few brief weeks off to allow The Sims there probably was not all a major release to have its day. The that much to see, and so it would be difSims was notoriously late at over five ficult for executive management to years and also over budget. Why did understand this game and get behind it. The Sims succeed when it achieved 68 Chapter 6: Business Context First The Diablo series has been a fantastic hit for Blizzard and is the standard and envy of the PC game industry to measure against. Blizzard first achieved outstanding financial success with Warcraft II, which built upon the classic real-time strategy gameplay of Warcraft I and polished it to a tight and smooth production that is the earmark of a Blizzard production. Blizzard’s model for making mega-hits is to set aside a large budget of money, have a large staff (Blizzard reportedly has about 200 full-time staff for a publisher of two concurrent titles), and take as long as it takes to make the game perfect. Blizzard knows they have a reputation for the highest quality games available, and each release they produce is an opportunity to damage that hard-earned reputation. The Blizzard label is probably the single most lucrative publisher brand in the industry. It is a common joke in the industry that if Blizzard ever needed cash in a hurry, they could print a box called StarCraft II or Diablo III and just ship a million empty boxes just for the pre-orders! This total focus on quality has of course repaid Blizzard (and its owners) handsomely. So Blizzard’s answer to the triangle is to bypass being on time and focus on quality and, to a lesser extent, budget. I just took a peek at Blizzard’s web site and noticed that in their description of one of the programming positions is a willingness to work long hours; apparently Blizzard games take as long as they need to as long as everyone is pushing hard. The statement of working overtime as a requirement of the job at Blizzard is a pretty clear indication that they too are worried about getting their games done in some sort of timely fashion. The point of this triangle is not to figure out which one of the triangle goals you are going to abandon wildly and throw out the window; the point is to identify in what part of the triangle you enjoy the most flexibility. Knowing where you are flexible will keep your project from breaking. Starfleet Command (SFC) is shown in the figure as on time and on budget. What this means is that quality was the most flexible aspect of the project whereas on time and on budget were not flexible. SFC was produced internally at Interplay during a time of great expectations with the impact of going public and the beginnings of tight fiscal policy. Interplay had many games in production at that time including three other Star Trek games—Klingon Academy, New Worlds, and the Secret of Vulcan Fury. Of all the Star Trek games in production, SFC was considered the underdog as our game focused on the real-time tactical simulation of naval starships based on the gameplay of a 20-year-old board game called Star Fleet Battles. Klingon Academy was a sexy 3D space shooter featuring over 110 minutes of live footage with star talent like Christopher Plummer. The Secret of Vulcan Fury amounted to taking the player back to the original series with fully digitized and animated faces of Kirk, Spock, and Bones. New Worlds focused on capitalizing on the real-time strategy genre and impressing the eye with ground troops of the Star Trek universe rendered in breathtaking 3D detail. We had a trick up our sleeve with Starfleet Command—a completely unfair advantage really. Our game, as I said, was based on simulating naval combat in space between majestic TE AM FL Y Team-Fly® Chapter 6: Business Context First 69 starships of the Star Trek universe. That is practically half of what the show is about if you think about it—photons and disrupters—just watch Star Trek II: The Wrath of Khan. We knew what we had and decided to make the best real-time tactical starship simulation we could. Along the way we broke new ground with real-time tactical warfare, and after we released SFC other titles like Dominion Wars and Bridge Commander attempted to find their own path down the naval starship simulation. With the fixed budget and the requirement to ship on time, our attention was focused on what would make the game: the real-time tactical combat. To create a foundation for our gameplay we licensed the mechanics of the hit board game Star Fleet Battles. Here we had a coherent set of gameplay mechanics that were play tested and improved over the years. However, these were gameplay mechanics for a hex grid, pen and paper game, not the game mechanics for a commercial game of the late 1990s. Glossing over the hours and hours of design discussions, we settled on an interface where the player sees a third-person 3D view of his starship traveling on an invisible plane, battling with an astonishing array of controls for the operation of the whole warship—the electronic warfare, the shuttles, tractors, transporters, marines, heavy weapons, engineering—bringing all of these systems to bear against the enemy starship in dark skies. This purity of concept was a godsend. I listed SFC as on time and on budget. Yes we were a little buggy when released, but we made a quiet hit game in a market where so many have failed—we made SFC. Quake and Diablo have a lot in common; both games are produced by development houses with the strongest reputations, both companies have a “when it is ready” policy for shipping their games, and finally both companies have paid their dues. The real interesting question is not when Blizzard and id ship their games, but how they got where they are today. How did they arrange to make their first hit game so that they could have a pile of money to use for their future games? Blizzard was kind enough to produce a recounting of their first ten years in the business in early 2001. The page is no longer posted at their site, and that is a shame. However, the history of Blizzard started with the name Silicone and Synapse. They, like all developers, started out doing work under contract for other publishers. It is ironic that Blizzard is now eclipsing Interplay, the publisher it worked for when it started in the industry. Blizzard was able to create Warcraft with the help of the Davidsons, who had an uncanny amount of wisdom to invest in a pre-Warcraft Blizzard. The history of id Software is also about ten years long, where John Carmack and crew developed the platform game Commander Keen featuring a football helmet-wearing child protagonist. It was Castle Wolfenstein 3-D published by Apogee that blew everyone away with its riveting 3D action and launched id into stardom to go on to create Doom I and II, Quake I, II, and III, and to be the engine behind dozens of other hit titles. These folks did not get lucky; they are creatively brilliant, have considerable business savvy, and have worked hard consistently for the last ten years 70 Chapter 6: Business Context First through an ever-changing set of parameters involved in making games. What you need to do as the producer of your game is to think hard, very hard, and articulate on paper what the business parameters are for the game you are making. These parameters—these restrictions and requirements—are not sources of angst to rebel fruitlessly against. Rather they should act as foci for your game’s creation; they should act as genuine opportunities to shape a successful vision for your game project. Questions for You to Answer Here are some straightforward questions; your mission is to take some time, grab a piece of paper, and write down the answers. n What are you trying to accomplish with this game? n When must you complete this game project? n How much money do you have to produce it? n Who do you have to get the job done? What to Do with These Answers An Ultra-Low Budget Game overwhelming majority of these projects. However, id Software used essentially this method to escape their stay at Softdisk. Chapter 25 contains an interview with one of the founders of Sliver Creek Entertainment, whose first game began as a weekend project. The goal for this type of project for the creators is most often to do the project for fun and to act as a compelling demonstration of their abilities to land a full-time position in the game industry. There are two principal paths to take: Make a small game or produce a modification to an existing commercial game (called a mod). JARGON: Mod is the name for a game that is made from the engine and assets of another game. If you are funding the project yourself with your free time and hobby money, you have a very distinct limit on how much money you can afford to spend on this project. The goals for your project should be correspondingly low. After performing your preproduction as outlined in Chapters 6 through 10 with detailed information in Chapters 14 through 20, your project should amount to no more than 500 to 1,000 hours of work per person to finish your project in a year. A way to partially solve your budget problem is to share your project with others: friends, family, and even folks across the Internet. Coordinating a group of volunteers to work together on a game project is very challenging, and their creators abandon the Ambitious mods that offer extensive changes are often called total conversions. Making a small game and making a mod are two different sorts of projects; each has its own challenges, and you will learn different things by accomplishing them. Many people might think that creating a demo of a simple real-time strategy (RTS) game that has incomplete AI, poor art, and no sound could still represent your passion for creating a large, commercial RTS. Yes, you might get your passion across, but in my opinion it would not be the best Chapter 6: Business Context First 71 demonstration. Just like consumers of games, we do not want to have ten features shoddily executed. Instead we would rather see just three or four polished features that are shippable. It is not interesting to know how long it will take you to implement feature X, rather it is much more compelling to know how long it will take you to drive feature X to shipping quality. The folks at Silver Creek Entertainment have taken this to heart and have produced the most excellent card games: Hardwood Spades, Hardwood Hearts, and Hardwood Solitaire. These folks have taken the very simple feature sets of these classic card games and have added gorgeous 2D graphics, flawless online multiplayer format, and clever added features such as customizing your avatar’s look and tossing fireballs at your opponents. Silver Creek started with an artist passionate about quality for his card games and two other developers; they now are running their own development company and are hosting their own online games without funding from a publisher. This is a significant accomplishment, for these folks have achieved what many developers aspire to—self-funded games; and they have done it in an area of high risk—online games. This is such an excellent model— driving a few features to perfection— that the folks at Silver Creek are not sending out their resumes and seeking a job working for someone else in the industry; instead, their hobby project was developed in a product with real value to thousands of players. To be successful with this model you need to find a game concept that is simple but playable and would require a minimum of engineering to get it functional. This would leave the balance of your time to create lush polish to that feature set. Creating a mod of a commercial game is another way to work with an ultra-low budget. Principally, two guys, Cliffe and Minh Le, created the phenomenally successful mod to Half-Life called Counter-Strike (CS) with some textures created by three other guys. They started with the Half-Life engine, which is in turn a variation of the Quake engine. Half-Life itself is a mega-hit from Valve Software that taps into the underserved market of players looking for a compelling story to engross them as they enjoy the action of the first-person shooter genre. Starting with a commercial hit game has the same compelling marketing potential for your mod as it does for a publisher’s sequel to a hit game. The Half-Life engine was eminently amendable to user modification, to the point where even the menus of the game support choosing a custom game type. The CS project was created by an experienced team that had worked together on Action Quake 2 and other mod projects before, so a single mod project was just the first step for these guys. It was their third project that really blew everyone away including Valve. This team, due to its experience and reputation on previous mod projects, received unprecedented support from Valve including design feedback, technical support, and even project financing. Counter-Strike perfectly illustrates a project that is on budget and is of very high quality, but the time side of the triangle had to be as flexible as they come. CS was released in the summer of 1999 as beta 1, and it took nearly two years for it to proceed through four 72 Chapter 6: Business Context First more major releases and ship as an expansion to Half-Life in retail. During production on these titles you will find yourself shifting secondary tasks to tertiary and primary to secondFixed Budget, Fixed Deadline ary when you are low on time and popping the secondary and tertiary I am most familiar with projects with tasks up when you have available time. these sorts of parameters, as all of my shipping titles have had these parame- It is vitally important to your producters. I have worked on one professional tion team that you do not make all title that had a ridiculously low budget, features must-do items that you reluctantly cross off as reality presents itself. PlanetNET, that never shipped. At Taldren we are now working on several People perform badly when under the cloud of being failures; for the sake of game concepts that have a variety of your team and your game, set them up business parameters to fulfill different roles for the future of Taldren. But fixed to succeed by prioritizing your features into these three different categories. In budget, fixed deadline games are what fact, your team members will cruise my reputation is built on. To make through their primary tasks so much these projects work you must walk backwards from your shipping date and more confidently that they will develop their features at the fastest rate possidetermine your beta and alpha dates. ble. Feeling like winners and making This will give you a gross amount of progress only enables them to get time available for your production and excited and want to knock off the secpreproduction phases. I am a strong supporter of preproduction and feel that ondary and tertiary items. Perhaps the most compelling reason to separate any project worth doing should spend your features into these three piles is about 15 to 35 percent of the total that all features inherently have a priordevelopment time in preproduction. ity, and you will make choices during This will give you a crude estimate of the man-months you have available for production. But it is only through formally acknowledging these priorities production. This is your budget for and writing them up in your plan that man-months. Now with your man-month budget you will derive all of the planning benein hand it is time to sketch out the fea- fits of knowing what you really must get done. ture set of your project. Break down your list of features into three piles: AXIOM: All games inherently have priprimary features, secondary features, mary, secondary, and tertiary features; and tertiary features. This section disthe wise developer will embrace these cusses how to identify your core prioritized features lists and turn them features and put the secondary and ter- into an asset. tiary features into other piles. You must Chapters 11 and 21 discuss specific then create a project plan that clears techniques for measuring progress and away all of the dependencies and risks task completion that enable the highest and supports the primary features. quality workflows. Chapter 10 outlines the project plan, while Chapter 20 drills down to details. Chapter 6: Business Context First 73 High-Profile/High-Quality Projects For the high-profile, mega-hit titles from well-established houses like Blizzard, id, Verant, and BioWare, a different set of challenges present themselves—all of them revolving around an industry and fan base with a high set of expectations for these great developers’ next titles. This means that quality must be so high that each release sets new high water marks for the industry to try to achieve. To understand better what goes into a mega-hit game, it is a great idea to look under the hood of a mega-hit and start pulling on the hoses and unbolting the pieces and looking to see how things fit together. I call this process creating a reverse design document after the technique of reverse engineering. Chapter 8 gives you an idea of the steps you should take when writing a reverse design document. For myself I wanted to see what went into the construction of Diablo, so I spent 27 pages of text detailing to myself how characters grew, how big the isometric tiles were, how the palette was laid out, how the inventory system worked, the user-interface, and all of the other parts that went into the production of Diablo, including the manual and box design. What I discovered astonished me: Diablo is actually a very simple game with a small set of features. This hit me like an epiphany. Now when I walk through E3 or flip through a game magazine I quickly project a mini-reverse design document in my mind for these games to get an idea of how complex they are. This led me to formulate Erik’s Axiom 13 of Game Design. AXIOM 13: As the complexity of a game increases, its likelihood of commercial success decreases at a geometrical rate. I highly encourage you to create a reverse design document for your favorite mega-hit whether it be Quake, The Sims, Total Annihilation, or another title. What you will find is that these games all have a clean, tightened feature set that is polished to a degree that their competitors have not been able to achieve. In fact, Michael Abrash decided to join id Software for many good reasons, but one of the reasons he chose to join the Quake team was because early in the project John Carmack wanted to put in a portal technology that would allow players to seamlessly jump from one Quake map to another in an extremely compelling version of action cyberspace. This feature was cut from production and in fact has yet to ship in a Quake game. This again is a reflection of the theme of concentrating on executing your features well. But without knowing better I would have thought these very successful developers would give no thought to adding features to their projects—heck, they don’t even have to be late. They could just hire teams and subteams to get these features done, right? No is the simple answer. The difference between a strong developer and a weak developer on your team is not just a linear difference in work output; it can literally be a tenfold, hundred-fold, or more difference in productivity. In fact for the networking code in Quake, John Carmack hired a programmer whose whole career was 74 Chapter 6: Business Context First in creating networking code. For some reason this did not work out well for Quake, and the programmer moved on. In two months time John Carmack came up to speed on the issues involved in networked games and produced a solid networking layer that was only 2,000 lines long and, as usual for John Carmack, set a new standard for multiplayer Internet gaming performance. From the time The Mythical Man-Month was written by Frederick Brooks, the idea that you could simply add up programmers like cantaloupe in your grocery cart has been under attack. Surprisingly, many people will attempt to add pressure to your project by asking you to hire more folks and get more done—or much more commonly get it done for a specified quarter. You certainly can get useful work done by hiring crack independent contractors and extra staff, but it is not a magic bullet. You need to organize and manage this extra talent. Adding additional staff requires more administrative overhead, and there is a critical threshold of number of staff in an area on a project beyond which you get diminishing and ultimately negative returns on work, even if the people on the project are competent. This is probably due to the increasingly complex communication required between a large number of people on a project as it grows in team size. These mega-hit developers have learned they cannot grow their teams to indefinite sizes and still produce clean, compelling hits. For this reason the features in these games are limited to roughly what their current team can produce. Walk Away Ultra-low budget projects should be simple games polished to a high degree or perhaps a port of an existing game engine into a new and compelling format. Fixed budget, fixed deadline projects should organize their features into primary, secondary, and tertiary piles and create their project plan in a manner that most supports the completion of the primary feature sets. High-profile/high-quality projects concentrate their best development team on a clean, tight set of features that they will execute to a quality level everyone else in the industry will then struggle to match. This will usually result in creating a barrier of entry that will place your organization ahead of the competition, and like compound interest you should be able to reap the result for years to come. Chapter 7: Key Design Elements 75 Chapter 7 > > > > > > > > > > > > > > > > Key Design Elements All games start as an idea, something like “Wouldn’t it be cool to be a space marine and blow up zombies on Phobos” or “Wouldn’t it be cool to be a pilot in a starfighter involved in an epic struggle to overcome the oppression of a star empire gone bad” or “Wouldn’t it be cool to drive modified street cars on Tokyo streets at night.” These idea sparks are often the source of long conversations between developers late into the night at the studio. Another potential starting point for a game is a licensed property; i.e., “make a RPG/RTS/action game using XXX license.” (Fans may want to play that license specifically. Major licenses include Star Trek, Star Wars, D&D, WWF, Lord of the Rings, and Harry Potter.) Chapter 6 discussed getting your business goals and parameters settled for your project before you start formal design and development of your game. This chapter discusses how to use the structure your business context and your game ideas provide and how to turn them into a game concept worthy of fleshing out into a game design document. Where the key design elements lie in the project’s lifetime 76 Chapter 7: Key Design Elements Business Context Shapes Design, or Does Design Shape the Business Context? First of all, I am not asserting that having your business context in hand will act as a magical tool that will turn any game idea into a well-thought-out game concept. It is only an important aid to assess the requirements that your game idea is implying. Some game ideas (such as the faithful recreation of Middle Earth where the whole world is modeled with strong AI, 3D graphics capable of great indoor and terrain rendering, where an unlimited number of players can join in together on both sides of epic conflict between good and evil) cannot be reconciled with the business parameters of two artists and a programmer looking to break into the industry, who have six months of living expenses available to them on their collective credit cards. That Middle Earth concept is an example of a game that will dictate the business parameters. If we take the business parameters of two artists and a programmer, they might want to recreate an arcade classic on the Nintendo Game Boy Color or Advance, use it to secure their first deal, and then move on to more ambitious projects. For many game projects there is a middle ground where the business parameters and the game idea go back and forth and refine each other. Perhaps the developer pitches a massively multiplayer game to a publisher who is wary of the costs and risks behind massively multiplayer. From these talks it is quite possible the developer will end up creating a game that exploits a license the publisher has rights to and features a much more modest multiplayer feature set. This is not an acceptance of a mediocre plan; rather it is a mature development of the idea into a viable concept. A viable concept is a game that people with capital believe will be seen through to completion, with a high probability of favorable reception in the market to overcome the inherit risk in game making. Reconcile the Business Context and Game Idea Early This process of refining the game idea and business context is the earliest stage of a game project. All projects reconcile their business contexts and the game idea at some point. Tragically, for too many projects this reconciliation only occurs after the project manifests itself by underperforming, usually by missing milestone dates. Some projects have a painful reassessment where senior management allocates more funds and grins and bears it. For other projects, senior management interprets this late reconciliation as an unpleasant surprise presented by an immature development team and consequently cancels the project. Allocating more funds and time to a project is a common occurrence, and because it is commonplace, too many developers think it does no harm to themselves and no significant harm to the publisher. That is fallacy; when a publisher is forced to spend additional Chapter 7: Key Design Elements 77 dollars and push back the release of the title, there are many negative impacts. First of all, the publisher must extend additional money to the developer. This is an obvious point, but it means that these funds are unavailable towards the development of another title with another developer or (worse for this title) funds may be drawn from the marketing budget to pay for this overage. The second impact is that the publisher has to delay when they will be able to start recouping their investment and see a profit that they can put to work in future games. The third problem is that the marketing effort is deflated as the awareness for the game is now illtimed, and it will be difficult for the game cover that marketing was able to secure for your game last quarter to have real value 18 months later. Right or wrong, the developer is the vendor and the publisher is the customer, and the adage that the customer is always right holds firm in this case, with the developer being tarnished by the reputation of poor estimating capability. Another reason to avoid going back for extra money and time from your publisher is that the business deal will never improve. A loss of royalty points is common; sometimes you will see a shifting of intellectual property rights. In the extreme sometimes the developer agrees to an assignment of equity in the project to the publisher. In the case of shifting equity to the publisher, the developer is strongly advised to get full value for that equity; no matter how small an equity stake the publisher takes, it will make all other publishers avoid doing business with the compromised developer for fear of a conflict of interest and confidentiality concerns. The developer is also losing time by going over his time budget, and spending more time on a project with the business deal worsening is not a good goal. The final reason to avoid a late reconciliation of the business context and game idea is to prevent team members from becoming disillusioned and moving on to another company. At Taldren we have released Starfleet Command, Starfleet Command: Gold, Starfleet Command: Neutral Zone, Starfleet Command 2: Empires at War, and Starfleet Command: Orion Pirates in less than two years. At the same time we gathered more fans and have always produced a profit for our publisher. Many of our employees are loyal to Taldren because of the steady pace of release; they know their work will be released and not wasted. The Effects of a Slipped Game 1. 2. 3. 4. 5. 6. 7. Less working capital for the publisher. The total advance is tied up longer than expected. Marketing dollars are often wasted as the hype bugle is blown too soon. The developer’s reputation almost always suffers. The business deal never improves for the developer. The developer loses the opportunity to work on other titles. Team members are in danger of becoming disillusioned, and the team may suffer uncomfortable turnover. 78 Chapter 7: Key Design Elements Ion Storm has to be the most infamous example of the consequences for late reconciliation of the business context and the game idea. Ion Storm was founded around John Romero, who is credited with the design of Doom—perhaps the greatest PC game ever. The UK-based Eidos was flush with cash, and John Romero left id just as Quake was entering its final stages towards release. Eidos needed to put the surplus capital from the Tomb Raider series to work, as all businesses must do. Tomb Raider was so successful that Eidos needed to get into a number of games, but established top developers were already booked, so Eidos would need to go with a less established development house. The idea of taking advantage of the designer behind Doom and creating a new development house is not a bad idea; in fact it is a good idea. Experience, a built-in fan base, and a great story for the media would create an environment that would be conducive to game development, one would think. Ion Storm was founded with the vision statement that design is king. Even this is not a bad idea; treated properly this would mean that Ion Storm would capitalize on its core strength—game design embodied by John Romero—and take advantage of existing game engines. Looking at how Ion Storm interpreted their vision statement would reveal where Eidos made their mistake. Ion Storm used the vision statement, design is king, to treat game development as a pure art form and lost respect for a strong development process. Ion Storm’s marquee project Daikatana suffered all of the ills described above. Whole engine retooling caused massive delays and required Eidos to double the already overgenerous advance of $13 million to $26 million to keep Ion Storm’s three projects rolling. Daikatana did not just lose face in the game press, it became the material for much derision, and even the local Texas newspapers saw the poor management at Ion Storm as a good story for a series of columns. Ion Storm not only suffered crippling turnover, but some employees helped feed the negative press storm by leaking to the press ugly internal email. John Romero was forced to hand over the company to Eidos, and their games shipped to little success. Ion Storm’s Dallas office has been closed by Eidos to what amounts to a large write-off of Lara Croft earnings and a reputation for Eidos to overcome. In fact the quieter Ion Storm Austin studio run by Warren Spector, which shipped the critically acclaimed Deus Ex, is now looking for a shiny new name to operate under to distance that studio from the ill-fated Dallas studio. The sad thing is that John Romero really can design games; just play Doom any day and you will see how amazing a game it was and still is. And Eidos turned on the cash to set up the game for greatness. It is just heartbreaking, really, to think about the potential of Ion Storm and to see it fall for lack of rigorous development methods. What can be worse than either pumping more money into a late project or canceling a project? Shipping it. It should never be done, but almost every large publisher has shipped a game well before it was finished. I don’t mean just with bugs; I mean before critical parts of the game were complete. TE AM FL Y Team-Fly® Chapter 7: Key Design Elements 79 Descent to Undermountain from Interplay is a classic example of a game that was shipped too early. The idea behind Descent to Undermountain was to take advantage of two key assets of Interplay: the Advanced Dungeons and Dragons license and the mega-hit Descent. Management at Interplay decided it would be a snap to plop down some fantasy environments, characters, and monsters to bash. Management decided the Descent game engine would be ready for immediate development into another title. Most publishers do not have a strong technical director available for code review. Yet at the same time many publishers also negotiate the terms of the publishing deals to either own the software engine behind the game or have a license to the software engine. Descent to Undermountain was a case where the revenue opportunity was so large as to prevent an objective review of what it would take to get the game done. The original business parameters for this title called for a budget of only six months of four developers’ time. No established development house was chosen to do the job; rather an ambitious independent contractor programmer stepped up, and various artists at Interplay contributed to the project. No project manager was allocated. Let me share with you what Gamespot thought of the results of this game after it slipped to three years and six times the original budget: From Gamespot review of Descent to Undermountain: But somewhere along the line something went horribly wrong, and now gamers are asking themselves two questions. The first arose merely out of befuddlement: How could the company that produced Fallout also be responsible for one of the lousiest games to come down the pike in quite a while? The second, though, addresses a much more serious issue: Why did Interplay ship the thing when it wasn't even close to being the sort of cutting-edge product the hype machine had led us to believe it would be? …There's probably no way to learn the answer to the first question, but—thanks to some very frank members of the Descent to Undermountain team—the answer to the second is now common knowledge. The game went out when it was scheduled to go out (in time for a Christmas release) even though it wasn't ready. That's not just me speculating; that's precisely what a member of the DTU team stated in a recent post on Usenet. When a project is three years in the making and six times the original budget, there is tremendous pressure to just ship the game. At the time, Interplay was receiving a huge amount of attention for Descent to Undermountain; everyone wanted a truly 3D dungeon romp. (Dungeon Siege, the first really 3D dungeon romping game, and BioWare’s Neverwinter Nights, which is a more detailed 3D implementation of D&D, weren’t released until 2002.) Interplay thought at the time that with all the hype, maybe, just maybe, the early sales in the first few weeks would be large enough to recoup a significant portion of the costs. It was also Christmas time when 40 percent or more of our sales as an industry happen. Interplay had three choices: 80 Chapter 7: Key Design Elements 1. 2. 3. Ship it now. Cancel the project altogether. (Remember lost money really is lost, and it is best not to chase it.) Find a real AAA development house and start over with a new large budget and two years more of development time. (Really the same thing as canceling the project.) Unfortunately for Interplay at the time, canceling the project or starting over with a new developer appeared to be more expensive than shipping the title. Let us see what Gamespot thought of this decision to ship the game: From Gamespot review of Descent to Undermountain: The lesson to be learned should be obvious: If you're gonna ride the hype machine, you'd better deliver the goods. Sadly, DTU doesn't even come close—and the worst part is that sometime over the next year or so we'll probably see this same story played out all over again. So what have we learned today? That pushing a product out the door before it's ready makes loyal customers angry; that game developers should keep at least one eye on what's going on in terms of technology when working on a new game; and that if you buy Descent to Undermountain after reading this, you get what you deserve. Descent to Undermountain shipped in a condition that was far below the industry standards of the time, Diablo and Quake II. The hype behind this game also crushed it. It is just possible that if Interplay had developed this title quietly, hard-core fans of AD&D and/or Descent might have bought 20,000 copies and been patient for a patch or two. I am not saying this is a great idea, but it is better than a hype storm. This is a poor way of doing business; the game industry shows time and time again that the mega-hits are just games that offer straightforward gameplay with strong production values. Wacky or niche games or poor craftsmanship are not rewarded. Just make a few quality titles and you will spend a lot less money in development, and your individual titles will have more capital to work with. Descent to Undermountain was a perfect case where the game idea and the business parameters were in conflict. If Interplay wanted a title in six months and had only a modest budget to accomplish it with, then Interplay should have commissioned the developers of Descent, Parallax, to create a cool expansion pack for Descent and they should have contented themselves with the sales of an expansion pack. Perhaps it was perceived that with Descent II already in development at the time, it would have been competing for sales. The other option was for Interplay to allocate the funds they were to later plow into Stonekeep II and hire a top developer to create a 3D dungeon romp of quality. Stonekeep II would later go into production for five years and then be cancelled. You must create a game that is compatible with your business context or fail. Chapter 7: Key Design Elements 81 Methods and the Unified Development Process Microsoft, the most successful software development organization on the planet, sells a lot of games. Microsoft is perhaps best known for its Flight Simulator franchise, but MS now owns Ensemble (Age of Empires franchise), Bungie (Halo and Myth, formerly the premier Macintosh development house), FASA Interactive, and Digital Anvil (the former Chris Roberts company working on Freelancer), as well as being the publisher for a host of externally developed titles such as Dungeon Siege. Microsoft is a large organization with many layers of development procedures that other publishers do not employ. The first thing Microsoft does when evaluating a developer is to send a small team of game development leads comprised of production, design, programming, and art to evaluate the strength of the team. A large part of this evaluation is to also evaluate the developer’s methods to determine if they are compatible with Microsoft’s and if these methods give Microsoft confidence that the developer has thought through their project and will deliver a great game, on budget and on time. Development methods must be good things judging by Microsoft’s success. What Is a Development Method? meth·od noun—A means or manner of procedure, especially a regular and systematic way of accomplishing something. We do want systematic game development; this whole book is dedicated to the presentation of various game development methods. Systematic and repeatable methods allow us to retain what worked and improve upon what did not work well. The alternative to using a method is employing ad hoc techniques over and over again and being successful only by good fortune. I rather like to make my own luck, thank you very much. The first method we need to nail down is how to reconcile your game idea and business parameters. I advocate using a comfortable subset of the Unified Software Development Process developed by the three amigos Ivar Jacobson, Grady Booch, and James Rumbaugh. Why Use the Unified Software Development Process? The simple reason is that the Unified Process is quickly becoming the software industry standard. The Unified Process has a long legacy dating back to at least 1967; at this time Ivar Jacobson worked for the telecom giant Ericsson. Jacobson had a radical idea for the design of the next generation telephone switching equipment at the time, a method we would now call componentbased development. For this project Ericsson modeled the whole switch system and subsystems as interconnected blocks. The relationships between these blocks was then articulated and revised. The dynamic processes of the switch were identified and modeled. Every message passing back and forth from each object was included in this model. This software architecture and object message compilation was probably the best technical design document of the time. This was a radical concept because software customers at the time were not accustomed to seeing a blueprint of the software 82 Chapter 7: Key Design Elements before the software engineering began. This method was not chosen on a whim; rather it met the demand that the software be robust enough for the telephone switching equipment to remain operating while receiving upgrades and patches to the software components of the switch in real-time. I will skip the middle part of the history behind the Unified Process; the point is that 35 years ago a repeatable method of creating great software was developed, and despite this, most software organizations have weak methodology. The Unified Modeling Language is the standardized text and visual language for the articulation of software design supporting the Unified Process. Beyond the development of Ivar Jacobson, Grady Booch, and James Rumbaugh, UML enjoyed broad support and major companies such as IBM, HP and Microsoft joined in the devel, opment and standardization of UML. Requirements Capture JARGON: Requirements capture— articulating the requirements the functional software must satisfy, such as to be fun or to run at 30 frames per second. What is the first step in the development process? Figuring out what we are supposed to do. There is a neat formalized term for this: requirements capture. Requirements capture is something you have already started. Those business constraints from Chapter 6 are some of the requirements the software must satisfy. How do we methodically discover the rest of our game’s requirements? The short answer is that there is no quick, magical method to sit down and write up in a single sitting all of the requirements your game must fulfill. Wait, don’t go away, I am still going to show you how to do it; it just involves several iterative steps. Use Cases First, if you have not already done this, write down your game idea on a single The purpose of a software development sheet of paper. Write two or three senprocess is to take the user’s requiretences that describe your game in the ments and transform them into a func- center of the piece of paper. Now in no tional software system. That transform particular order write down the major stage is what we game developers are functionality of the game in an outward, doing when we make games. We take radial manner from the game idea in the the vision of the gameplay—how it center. The larger, chunkier aspects of should play—and turn that into a finthe game should be close to the center ished game. and the detailed ideas farther away. For example if you are designing a role- The role of a development process Chapter 7: Key Design Elements 83 playing game, you have characters; write that down. Characters have stats; write that down. Characters have names; creating the characters’ names is a feature. What you are doing is brainstorming the gross feature set of your game. This particular method of putting the game idea down at the center of the page is good to get you started if you have not put a lot of effort into your game design document yet. The immediate goal is to identify all of the core activities the player can perform in your game. Each of these core activities is composed of many individual actions the player performs. Each of these actions is called a use case in the Unified Modeling Language. Brainstorming features 84 Chapter 7: Key Design Elements JARGON: Use case—an interaction between an actor and the software system. A fully articulated use case is composed of both text describing a sequence of actions and a graphical diagram showing the relationship of this particular use case with others in the system. Collecting these use cases and writing them down will drive our process to identify the requirements of our software. The software requirements will then help us develop the architecture for our software. The use cases represent function, and the architecture represents form. The Unified Process is called use case driven because it is the effort to capture our use cases that drives the development. All of our future efforts in the construction of our software are to further the realization of these use cases into a functioning software system. Now, what exactly does a use case look like? and the relationship line. The stick figure is called an actor. Actors represented by a stick figure are most often users of your software, or players of your game, who are interacting with the game. It is better to use the abstract term “actor” so you will see all of the external users of your game system such as the single-player player, the multiplayer player, the system administrator, and the database server of your online component. After identifying your actors, the use cases will flow rapidly. The use cases are the unique interactions between the actors and the software system (game). The use cases are represented by a simple oval with an active verb phrase such as “withdraw cash” or “analyze risk.” JARGON: An actor is a user, either human or another external system, that is interacting with the system under analysis. JARGON: A relationship is a line drawn between actors and use cases, sometimes with extra notation that further describes the type of relationship, such as <> and <>. The level of articulated rigor in a diagram should be reasonably proportional to your needs. For example, if it is important to describe the relationship line in better detail, use a one-word A simple use case diagram featuring the use of an descriptor between the less than and automatic teller machine greater than symbols. Common examples are the relationship descriptor of It turns out one of the fundamental ten- <>, <>, where ants of UML is that the language shall extends would communicate that a parbe extensible, flexible, and ultimately ticular use case is really a special case serve only to aid the process of distillof a simpler base use case, and uses ing and communicating the system would indicate that a particular use case requirements. This ATM transaction employs another use case as part of its diagram uses only three UML symbols: action. the oval use case, the stick figure actor, Chapter 7: Key Design Elements 85 I shall now plop Pac-Man down on the cold steel of our examining table. Cutting the skin of a clean, tight, Display System Display maze Display characters and their animation Display score Display high score Display credits View movie (Ms. Pac-Man) mega-hit game, let us take a look at the innards of Pac-Man and see some of these use cases in action: The use cases of Pac-Man that are related to displaying and viewing Player Input Insert coin Push coin return Choose single player or multiplayer Move up, down, left, or right The use cases of Pac-Man related to player input 86 Chapter 7: Key Design Elements Game Object Interaction Wall collision Eat dot Eat power-up dot Eat fruit Eat ghost, send ghost to center of box Pac-Man dies The game object interaction use cases of Pac-Man Miscellaneous Receive extra man Enter initials Miscellaneous use cases for Pac-Man We can also take a higher-level view of Pac-Man and combine these low-level use case diagrams into a generalized use case view of the software package as a whole. See the diagram to the right. Now you have a good tool for breaking your game idea down into visual parts that describe the required functionality. This is very important, because when your game exists only as an idea expressed in a half-dozen sentences, it is difficult to see the complexity of your proposed game and reconcile it with your business constraints. Looking at the UML diagrams for Pac-Man, we confirm our understanding that this is a very simple game. Looking over the diagrams I can The combined use cases of Pac-Man Chapter 7: Key Design Elements 87 see only four roles: a programmer for the 2D display system, a programmer for the game mechanics, an artist, and some audio. This of course is a very small game, and a solid Pac-Man clone could happen inside a weekend for a two- to four-person team. This process of understanding how something else was put together has a fancy name—reverse engineering. I highly encourage you to perform some reverse engineering on other games that you are familiar with. We continue with some sketches from other games. Case Studies It is now time to apply these tools to modern games that are of greater complexity than Pac-Man. Each of the following two games, Diablo and Gran Turismo 3, has enjoyed legendary marketplace success, and each has spawned a lucrative franchise of sequels, expansions, and licensed products. Is there a common thread between these games? Did the developers in each case just get lucky, or were the developers just extraordinarily brilliant? I honestly do not know how much luck was involved, but someone with a lot of intelligence, skill, and time honed these two game concepts into production plans that have succeeded far beyond the industry standard. I can show you the elegance in the design of these games, illustrating how, looking back, these were mega-hits from their conception. concept behind Diablo was to make the user interface priority #1, not the story, not the size of the game, not the number of different character types, not customized character appearance, not a rich role-playing game mechanics set; no, the focus was the user interface. Indeed, the mouse controls were a stunning left-click on monsters to attack, left-click on chests to open, and right-click to cast a spell. The interface itself was appealing to look at with large glass spheres that held blue and red liquids representing remaining life and mana (energy to cast spells). Shortly I will more carefully break down the use cases of Diablo; but there is a tremendous amount of courage and insight behind the user interface design of Diablo. In the summer of 1995 I was up late one night with a bunch of other game developers talking about games Case Study I—Diablo we could make. I remember we sugDiablo is a computer role-playing game gested just a simple variant of Gauntlet, for the PC developed by Blizzard the arcade classic where you just went North, originally an independent devel- around bashing monsters, collecting oper of another name bought by gold, and powering up. I remember how Blizzard during the development of we all laughed at the time and said Diablo. Diablo featured the killing of there was no way it could be viable. No hordes of monsters like skeletons, wan- publisher would see the game as feadering around in a dungeon, gathering ture-rich enough to fund. Perhaps as a gold, and collecting magic items all in bit of forgotten shareware, but no way it the quest to vanquish ultimate evil—all could be a commercial game. At that straightforward fun stuff. The key time RPGs such as Bethesda’s Elder 88 Chapter 7: Key Design Elements Scrolls series were vast worlds with hundreds of NPCs, dozens of cities, hundreds of locations, actual weather, and time of day. Imagine making a game that left out all of these features and just concentrated on a tight interface and high production values—that was Diablo. Use Cases of Diablo Diablo is a simple game, a polished game with strong production values such as superb voice-overs and movies, but we will see that Diablo is a simple game behind the features. I will cover the major features and elements of the game; I do not propose to create an exhaustive reverse design document in this chapter. Display System Terrain: Draw floors. Terrain: Draw isometric walls. Terrain: Color cycling special effects for water and lava (tiles do not animate). Terrain: Ghost walls when a character is located behind the wall. Characters: Render and animate characters (2D sprites composed from 3D rendered models). Game Objects: Colored outlines for interactive objects such as treasure chests, magical rings, monsters, and non-player characters in the town center. Spell Effects: Display any one of a couple of dozen spell effects with dazzling animations and cool sound effects. Menus: Display menu choices. Movies: Display the intro and exit movies to the player. Audio: Hear sound effects. Audio: Hear music. Audio: Hear voice-overs. Game Object Interaction Move Player Character: Left-click to move the player character. Left-click Object Interaction: Interpret the left-click on an object automatically by object type to mean open a chest, attack an enemy, or move the player to a location as above. Load Level: When the player directs their character into special trigger areas on a map level, load the target map level. The view related use cases of Diablo TE AM FL Y The game object interaction use cases of Diablo Team-Fly® Chapter 7: Key Design Elements 89 Right-click Object Interaction: If the character has a spell bound to their ranged action, cast a spell at this location on the map or on this character (this could be either an offensive spell on an enemy or an aid spell on an ally). Otherwise if this character has a bow, fire an arrow at the character indicated. Character Management Name Character: Small feature for user customization to allow the player to bond with their character. View Character Stats: View attributes, health, experience points. Allocate Character Attribute Growth Points: When the character achieves the next experience allow the player to choose where they want the growth points to be allocated, choosing from strength, dexterity, intelligence, and constitution. Inventory: Display the character’s inventory in a “paper-doll” fashion with sockets for the backpack, belt, helmet, hands, pants, boots, and tunic locations. Inventory: Allow the player to shuffle objects about in their backpack to “make room” for new treasure and to abandon lesser treasure in favor of higher prized treasure. Validate the placement of inventory items based on their type. For example, healing potions can be carried in the backpack or in the belt pouch but not in the helmet slot. The character transaction use cases of Diablo Quick Analysis of the Use Cases of Diablo Looking over the use cases of Diablo you will notice that I have partitioned Diablo into three subsystems: Display System, Game Objects, and Character Management. Below is a short discussion of these systems. The display system is just a 2D isometric engine that is capable of rendering animating 2D sprites (quite probably used for both the characters and the spell effects). This graphics technology was hardly groundbreaking in 1997; isometric engines have been around since Q-bert in the arcade. The The aggregate use cases of Diablo game also uses a 256-color palette incidentally. There is no question that the graphics in Diablo look strong; the art direction was strong and led to a consistent look that was foreboding and well supported the theme of the game. 90 Chapter 7: Key Design Elements Touching on character management for a moment, the display system is called upon to also render menus such as the menus of the town shopkeepers who have stayed behind after the arrival of demonic forces to make a profit selling adventuring gear to the player’s character and the inventory, spell, and character management menus. These again are just menus, displaying customized fonts, buttons, icons, and cool negative space textures. The characters in the game animate well due to the aggressive use of 3D rendering to produce the 2D frames from which to composite the 2D sprites. This technology is not new either; our example Pac-Man uses just a few frames from open mouth to closed mouth to animate our hero, and the Wing Commander series used an array of images (about eight to sixteen individual images) from all angles around the starfighter to produce its “3D” starfighter game. The plan for Diablo was to again use established technology but take it to a quality level never before seen in games by using over 5,000 frames of animation for just the three main protagonist characters. This dedication to visual fidelity represents a lot of confidence in staying with established technology but taking it to a very high level of quality. I know of another game I will not mention by name that became severely distracted with the pursuit of volumetrically projected pixels, known as voxels, for the rendering and animation of their characters. This distraction helped to cripple this title. The game object interaction system runs the heart of the game. This is a game of hack and slash and loot gathering. The context of this hack-and- slash has something to do with a crystal in somebody’s head, demons from hell, a butcher, and dead townsfolk—plenty of motivation to keep our player character hacking away at the monsters in the game. The game object interaction handles the combat, spell casting, opening doors and chests, triggering traps, and level changes. Notice that my use cases above do not have any detail on how combat, spell casting, or the opening of doors and chests works. Those are detailed use cases that would be covered in the design document; this chapter is focusing on the key design elements of the game in the effort to be sure we have the correct scope for our game. My use of UML use case notation ’s has been purposely slim with the use of just the simple table format of major user interactions and a few diagrams to show the relationship of these interactions with each other. In later chapters I will discuss more advanced use cases as we progress through the game design and head into technical design. Case Study II—Gran Turismo The Gran Turismo series for the PlayStation and PlayStation 2 platforms published by Sony is all about racing cars. Every conceivable subgenre of racing has been explored over the years as well as many sequels offering the latest technical wizardry for themes already visited. Racing cars have been a staple of video games since the days of the Atari 2600 with Night Driver, where the road and terrain are a solid field of black demarked thoughtfully with some magenta lane markers. Nighttime racing has continued to evolve to Tokyo Street Racer on the PS2 and Project Gotham on the Xbox. Racing games Chapter 7: Key Design Elements 91 deliver an experience that almost everyone wants to do—race cars. Some want to race at night, some off road, some want to race taxis, some want to run over pedestrians, but hey, there is a racing game for everyone. What is it about Gran Turismo that makes it a mega-hit? Was it luck? Was it a large budget? Or was there some sort of planning and direction behind Gran Turismo? I am presenting a case for thoughtful planning. Gran Turismo’s (GT) vision statement was most likely something like “The best racing simulator on any platform.” To back up that vision statement we need to look into what it would mean to be the “best racing simulator.” The best is so encompassing in its superlative that Sony set out to dominate all other racing games. Hmm, that is a tall order. The first step is to pick the type of racing Sony would model. In the end, Sony chose to model a variety of racing from raw amateur racing of minivans to world-class events featuring million-dollar racing machines achieving the highest form of automotive engineering. So, at first glance it would appear that Sony violated the design guideline of focusing on one game and a tight set of features and doing them well. However, if we take a look at how they presented these various classes of racing to the player, we will see that it was a seamless presentation of gameplay from the lowliest of minivans to the Suzuki Escudo. When you load up the simulation mode of Gran Turismo for the first time (it doesn’t matter which version), you are given a small amount of credits to purchase your first racecar. Taking a look at the various car manufacturers, the player has only a couple of choices in the beginning of the game. After spending all his cash, the player then sets out to race some beginner races to build up a supply of cash so he can modify his car. The car modification gameplay is the hidden weapon of Gran Turismo. Here players can ogle new tires, polished ports, oversized turbos, and a host of other modifications to their car. The exhaust improvement conveniently enough has the highest bang for the buck and will most likely be the first purchase for any player. Here the player bonds with his car, and all the cool parts available drive the player to go back to the track and keep racing. This context for the racing is compelling. It is the same inventory/party growth dynamic from a role-playing game like Diablo—a most compelling feature. This racing around a track and modifying the car goes on and on throughout the whole game. What changes are the events, the tracks, the competition, and most importantly, the car the player is racing. Gran Turismo features hundreds of cars, dozens of tracks, and scores of events. The events are classified into licenses from Beginner to International A. Players can always find a race and almost always can earn some cash to make forward progress on acquiring new goodies for their car. This car modification meta-game is what ties all of Gran Turismo together and presents to the player a world where they can start with a modest real-world car, and through racing, modifications, and licensing they too can be an international racecar driver. This is the brilliant vision behind Gran Turismo— it slowly builds up to the super cars, 92 Chapter 7: Key Design Elements and all along the way the player is hooked and believes in the world and knows why he is playing this game. Later in the series Gran Turismo added rally racing. This additional mode of racing was also seamlessly integrated into the core game. Indeed, the player’s rally racing cars just need to change the tires to racing slicks and they would often do well in the pavement events. In classic arcade fashion, new tracks would only be revealed to the player after completing a racing series or a licensing program. The rally events in the later GT series upheld that tradition with their own set of rally tracks to unveil. The Gran Turismo series is the greatest of the racing games because it fully delivered on the gameplay that is central to racing and takes players from knowing nothing Car Driving Controls Press the Gas Pedal Use the Normal Brakes Turn the Car Left or Right Shift the Gears Up or Down Use the Emergency Brakes about racing cars to being able to carry on an extended conversation about gear ratios and coil-overs. I justified Gran Turismo’s success without ever mentioning that the game has always boasted the most realistic physics model for its racing, the most gorgeous graphics, and a complete aural experience second to none. All of these technical features are of course critically important to an electronic game; however, it is the key features of a game that will lead to success and enable the project to fully realize the efforts of the whole game development team. Use Cases of Gran Turismo Here are the key features of Gran Turismo 3 distilled into some use cases for review: The player input use cases of Gran Turismo 3 Display and Audio System Render the Track, Terrain, and Sky Render the Cars Render the Special Effects Play Sound Effects and Music The display and audio use cases of Gran Turismo 3 Chapter 7: Key Design Elements 93 Shell Activity Menus Access Buy Car Access Garage Access Wash Car/Oil Change Access Race Car Access Modify Car Access Licensing Tests The shell menu use cases of Gran Turismo 3 Modify Car Browse Major Systems: Engine, Transmission, Aerodynamics, etc. Review Individual Item: Read the stats of this item and see how it would look on the car if it is an external add-on or what the change to weight and power would be if it is a performance item. Purchase Item: Buy the specified upgrade part. Install Item: Have the newly purchased item. This especially makes sense for the purchase of tires; it is useful to the player to be able to choose from a suite of tires. The modify car use cases of Gran Turismo 3 player has to play with. Driving the car and modifying the car is the game; everything else is in context of these Again, this chapter is not discussing how to complete a detailed design doc- two activities. Gran Turismo is successful largely ument, so I have only covered the due to a clear vision and plan for the higher-level functions of Gran Turismo. game. It was perfectly designed to capBut in two areas, driving the car and modifying the car, I drilled down to the ture the largest segment of the market who would enjoy racing games. In fact individual interactive activities the my father and his best friend went out and purchased PlayStations after playing Gran Turismo 1 at my house and went on to compete with actual cash prizes for virtual driving seasons. These two men in the over-50 demographic were not hard-core gamers; they were mass-market consumers who bought the PlayStation just to play Gran Turismo. That is a true hit. The use cases of Gran Turismo from five miles up Quick Analysis of the Use Cases of Gran Turismo 94 Chapter 7: Key Design Elements The Key Design Elements of Your Game game design that are distracting in complexity? Are these parts only fun to I am sure you are now comfortable with a hard-core set of fans? Are these features hidden from the novice player? this light introduction to UML use Can they be cut altogether? cases. They are hardly more than a Take a look at your design; are you table of actions and a simple diagram sure you are only making one game? I composed of a stick figure and bubbles of action. Now I want you to think about think a lot of the projects that slip by the interactions of your game and write years make the mistake of trying to fold more than one game into a single game down its use cases. The methodical way of discovering project. You do not need to make more than one game to be competitive. Just your use cases is to focus on the core activity of your game and write down all make a small set of features that are the things the player does in the core of inherently fun, make those tight, and take the production values as high as your game. Work your way outward, possible. This is how a hit is made. writing down the other activities you have planned for your game, such as The Battle of the Counterterrorists buying gear, building a house, research- Games ing flame throwers, learning a new There are two games that neatly make spell. Keep working outward until you the point I am discussing in this chapcan’t think of anything you missed. At this stage we are looking for the major ter, nailing the right key design elements. These two games are Rainbow activities, so don’t think about how many buttons the save menu will have, Six and Counter-Strike. Both of these games feature special operations type just what are the big interactions protagonists working as a team to between the player and the game. defeat terrorists and other modern day Then sort these activities into groups based on similar functionality as bad guys. An experienced development team produced one of these games with I have done with Diablo and Gran a full development staff for an estabTurismo. Finally sketch out the use case diagram complete with the player lished publisher. The other game was actor and your use cases. It is useful to developed principally by two fans who create diagrams for each group of activ- have had experience making mods with modest financial backing of a developity. You have now articulated your ment house. gameplay in both an easy-to-read text Both of these games are successes format and graphical format. These use and I would be proud to have been a cases will be the basis of refinement for team member in any capacity on either the game design and technical design stages. However, in this chapter we are of these two projects. That being said, Counter-Strike clobbered Rainbow Six. looking for key design elements. ExamCounter-Strike is the mod produced by ine your groups of activities and look hard for a set of activities that stand out a small staff of fans working part-time, while Rainbow Six is a full game with as potentially unnecessary to the core many man-years of effort. If game of your game. Are there parts of your development is so hard, how could Chapter 7: Key Design Elements 95 these fans have done so well compared to the pros? While poor technical execution will never make a hit game, the answer to this question lies again in the key design elements of Counter-Strike versus Rainbow Six. Are We Playing a Mission or Planning a Mission? I think the preplanning of the missions is what prevented Rainbow Six from taking off to a higher level of success. The problem with such a detailed modeling of the preplanning stage is that it was cumbersome in three ways: First, The Key Design Elements of the player already had context for the Rainbow Six missions through the campaign strucRainbow Six was the earlier of the two ture and the team management feature games; to some degree this can never sets; second, it was cumbersome due to be a fair comparison, as the Counterthe user interface of the preplanning. It Strike mod team had Rainbow Six avail- was like having to act as some kind of able to experiment with and to refine. game scripter, programming your teamRainbow Six was designed for singlemates. And finally it was cumbersome; player play, and while it did have multi- each time you died or otherwise failed player mode, the game was much more on your mission, the player would playable in its single-player mode. break out of the cool, immersive action Rainbow Six featured an extensive of the mission and be forced to calculate campaign structure where you managed new scripting paths for their AI teamthe team members of your elite special mates. All of these awkward bits leaked forces. This team management would out throughout the game-playing expeappear to be at first glance quite fun rience, leaving me wondering if the and supportive of the context of playing designers of the game ever came to the missions of Rainbow Six, much like agreement about whether the game Gran Turismo, and that might be true. was about playing the mission or playHowever, the Rainbow Six team added ing the premission planning. another context layer to the game: misRAY SPEAKS: I totally agree. I recall sion planning. Here the player planned being very irritated with how difficult it out the mission to such a degree that was to equip your party, choose your they could tell their team members party, plan out your party’s actions etc. when to throw the flash grenades and There was no learning curve; instead which doors to break down and which you were dumped into an equippingto sneak through. After the planning your-character simulation, which, fundamentally, was not the game I had stage was complete, the game acted somewhat like the blend of a movie and thought I was purchasing. This created a perception/reality gap for the cona game experience. The movie experisumer that made people not want to ence came in where your AI teamplay the game. mates, whom you gave instructions to prior to mission start, would follow your orders and have whatever success might befall them; the game part was that you still had interactive control over your character. 96 Chapter 7: Key Design Elements game. Players would carry their credit balance forward each time the mission was over, and the frag counting would Counter-Strike was designed to have continue. Thus, Counter-Strike was only a multiplayer mode; not even a designed in the beginning to be a training simulation against bots like replacement for the endless multiQuake III was available. CounterStrike’s brilliance is much like Diablo’s player fragging and instead be a much more compelling way of playing in its courage to strip away game feaextended multiplayer first-person tures and polish the core game until it is humming with game shine. For years shooter action. All of this was accomin first-person shooters, when you died plished by the thinnest of user interfaces, on top of Half-Life’s version of you instantly respawned to frag again. the Quake engine. This is of course a load of fun, as one In my opinion the Counter-Strike could easily spend a few hundred hours team really understood the gameplay blowing away your friends before you experience they wanted to deliver— get bored. But eventually people did the most visceral counterterrorist get a little burnt out on straight death match, and a desire for something more gameplay experience, period. In the case of the Rainbow Six team, I think manifested itself. These explorations they were handicapped by the source for more came in the way of mods for Quake and Unreal that had different vic- material from Tom Clancy’s Rainbow Six in choosing to model the extensive tory conditions for winning such as preplanning stage of a mission. That capture the flag. The team that prostage is no doubt realistic and the larger duced Counter-Strike took the idea of portion of the job in a real countera mod with context to the next level terrorist mission, but it just gets in the (that, by the way, is an overly worn way of having fun hunting terrorists. phrase in the industry, but it sure is And we are in the profession of deliverhandy). ing fun, not realism. Realism should The next level of gameplay in a only be used to create fun, not detract first-person shooter was to wrap an from it. economy about the fragging of the game through credits one earned by Most Popular Multiplayer Game winning missions and getting frags. This economy would enable the player It is interesting to see that CounterStrike is the most popular multiplayer to buy larger and more capable weapons, armor, and grenades, which in turn gameplayed online, with anywhere from 25,000 to 60,000 simultaneous players. would enable him to perform even One could say that Half-Life itself was a better and potentially get even cooler equipment. This feature combined with mega-hit with over two million copies the idea of a death where the player had sold, whereas Rainbow Six was a more modest success, and use that argument to sit out the rest of the turn really helped to focus the player on the harsh- to explain why Counter-Strike is the more popular counterterrorist game. ness of the Counter-Strike world and However, that argument fails when you put some good tension back into the realize people do not play games they The Key Design Elements of Counter-Strike Chapter 7: Key Design Elements 97 do not want to play. Sure, marketing can help a game get off the ground to some extent, but the games business is still dominated by word-of-mouth sales where one fan recommends the title to another. The big titles that receive large marketing budgets are also fun and playable games that enjoy strong word-of-mouth sales. Unlike the movie business, an aggressive marketing campaign cannot save your bacon. There is a long-standing tradition of going to bad movies just to see how bad they are; this does not happen with games. Games are too expensive at about $50; no one is inclined to buy a game just to see how bad it is. However, a bad movie has a couple of chances. First of all, just seeing what mischief with toddlers Arnold Schwarzenegger has gotten himself into complete with some buttered popcorn, a fountain soda, your friend’s company, and a walk about the mall is a good entertainment value. This movie will go onto DVD, VHS, rental, cable, then prime-time TV, and eventually the USA channel—plenty of ways for a non-hit movie to recoup and make a small amount of money for the studio. The 50,000 people playing Counter-Strike online is even more impressive when you think about the ratio of people playing the multiplayer portion of a game relative to the single-player portion. It has been casually measured across a number of games, excluding the massively multiplayer online roleplaying games, that only about 5 to 15 percent of the purchasers of a game will go on to play it in its multiplayer format. Thus Counter-Strike was much more successful than Rainbow Six, and it was working with only 5 to 15 percent of the counterterrorist market. Of Intersecting Sets and Elite Forces A second-tier game will sell its most copies in the first few weeks when the early adopters who have kept on top of all the previews will buy the game. During this time period the online reviews are written up. To my surprise it appears that strong reviews cannot sell a game either. The most excellent Elite Force (not anywhere close to being a second-tier game) developed by Raven received the most stellar press reviews one could ask for, including game of the year from most publications. Built on the Quake engine and developed by a top developer, it had lavish press coverage generating plenty of awareness before the release of the title. The title was reasonably on time and reasonably bug-free. The team behind the game was so into the game, they produced a free expansion pack. Elite Force was firmly expected to be a major hit inside of Activision. I do not know the actual numbers on the internal return-on-investment worksheets, but I have heard they were expecting 700,000 to 1,000,000 units in the first year worldwide. Elite Force went on to do about one-third of those numbers. Why? Why did Elite Force not succeed when not a single person at Raven, Activision, or the press could have set the game up better for success? Is it bad luck? Is the gaming public so fickle? I have a theory why Elite Force failed to meet Activision’s expectations. First of all, the game did sell well at approximately 300,000 units generating a gross revenue of $15 million. That is enough money to make a living for all involved and keep at it. However, I think it is the expectations that were at 98 Chapter 7: Key Design Elements RAY SPEAKS: This certainly is an art form, but I think it can be done; it’s just difficult. Creating the correct impression on the fans of both genres and making the parts that don’t appeal to the other genre’s fans at all times accessible is probably the hardest thing to implement, but this is critical to achieving mainstream success through selling to a few hard-core genres in a cross-genre game. The two markets for Elite Force were the Star Trek gamers and the firstperson shooter gamers. Activision has been working hard for years trying to find a breakaway hit for the Star Trek license they paid so dearly for, and teaming up with world class developer Raven and using the fabulous Quake engine should produce a lavish 3Dgame with production values far and above any that a Star Trek gamer has seen before. And for the first-person shooters who are tired of blowing monsters up in worlds freshly created with little or no backstory, Elite Force offered the Star Trek universe, which consumers have had exposure to for TE AM FL Y Team-Fly® fault; I don’t think the game could ever hope to sell more units than it did. Sure a truly immense advertising campaign with television commercials played 20 times a day on all channels and appearances of the game on all of the latenight talk shows would have sold maybe 100,000 to 200,000 more copies, but Activision would have had to pay for each copy they were selling. My theory is that when you are experimenting with genre crossing and blending, be sure you are creating a union between the two or more sets of players you are marketing to, and not creating the intersection between these markets. over 25 years. Sounds wonderful, so why did this game not sell a million copies or more? Warcraft II was just a sequel to a game of orcs and humans gathering rocks and trees and banging on each other. That sold millions of copies; why shouldn’t Elite Force sell a million? The reason is in the key design elements themselves; the very strategy used to make a hit—a cross between Star Trek and first-person shooters—is what held Elite Force back. Let us first take a look at Elite Force from the perspective of a Star Trek gamer. Star Trek is about a starship named Enterprise exploring the galaxy on romantic adventures that are solved through cleverness, diplomacy, or the gunboat diplomacy that the Enterprise can deliver with photons and phasers. The Star Trek gamer is looking to live the experience depicted in the television episodes and movies. These episodes feature fantastic science, starship combat, and exploring various social themes in a futuristic context. Star Trek does feature combat between individuals in the form of the hand-held phaser, a device that you just point and shoot to disable or to disintegrate. This weapon reveals an utter disdain for prowess of personal martial skill; this hand phaser is almost a nerd fantasy where they can get back at every childhood bully by just pointing their garage door opener—and bzzt!— no more enemies. The Star Trek gamer is not looking for a first-person shooter; there is nothing in the Star Trek universe backstory that leaves the player wanting to explore a shooter. The most successful Star Trek games have been the adventure games 25th Anniversary and Judgment Rites, as well as the Chapter 7: Key Design Elements 99 starship games of Starfleet Command, Starfleet Academy, and Armada. From the first-person shooter perspective, an FPS player traditionally looked for the technically impressive and challenging games such as the Quake and Unreal series. However, after the release of the story-rich Half-Life, the industry realized that the FPS crowd would love to have a good reason to exercise their martial prowess. The creepy world of Half-Life is a good reason, the pulse-pounding excitement of World War II through Day of Defeat is a great reason, and hunting terrorists with a submachine is always great fun. But again the Star Trek universe lacks any compelling imagery of personal combat. Sure, Kirk would slug it out with the occasional alien, and Spock could put someone to sleep by pinching them; either way, Star Trek lacks that visceral appeal. Star Wars, on the other hand, has a glorious tradition of martial combat on the personal scale through the use of light sabers. This style of combat was indeed a strong success with the Jedi Knight series from LucasArts. Finally, let me repeat, Elite Force was not an unsuccessful game; it was a great game, very well produced. And missing the expectations set for it is not a reflection on the execution of Elite Force, but rather a reflection on the key design concepts of the game. Some Straight Questions to Ask Yourself The case studies I presented introduced use cases from the Unified Modeling Language and illustrated what I mean by determining the key design elements of your game. I ask you to pause just a moment before you wield your scalpel and slice off the most extraneous bits of your game design. I would like you to first get a bit more material down on a second sheet of paper to consider while you review your key design elements. What Genre or Genres Does Your Game Feature? Write down your game’s genre or genre blend, and why. Will the Game Be Single-Player, Multiplayer, or Both? Does your game play well as a singleplayer game but perhaps not make much sense as a multiplayer game? Or is it the other way around where it takes real humans to play against to make it fun? Or is it reasonably fun either way? Write down single-player, multiplayer, or both, and why. What Is the Platform? First, what is your game’s genre, such as adventure, role-playing game (RPG), real-time strategy (RTS), real-time tactical (RTT), action, first-person shooter (FPS), puzzle, sports, or some other genre? Or is it a blend of genres? Which platform are you targeting: PC, handheld, Xbox, PlayStation 2, or GameCube? Write down the platform or platforms you are targeting, and why. 100 Chapter 7: Key Design Elements What Is Your Target Market? Is this a game anyone could enjoy? Or is it targeted for the core game market of males 18 to 45 years of age? Are you targeting women as well as men? Children? What is the violence level in your game? The language? Sexual content? Write down your target market, and why. What Major Technologies Are You Using? Is your game to be 2D or 3D in its fundamental presentation? Will it use a commercial engine? Is there something special about the physics? Perhaps you envision cell-shaded rendering of characters or the scene. Write down the major bits of technology you will employ in your game, and why. Now What? Notice I did not give any opinions or suggestions on how to answer those questions or which answers I thought you might choose. It is not my place to tell you that a cell-shaded 3D RPG would be the next big thing on the Game Boy Advance. No, the answer to the questions above need to come from your heart, that place of inner vision where you can see and play your game in your mind’s eye. That gameplay in your mind—I want you to write that down. This is your game. If you told me your game concept, I could offer suggestions and opinions, but they would be just that—opinions and suggestions. For this game of yours to be a success you must be able to have a strong vision for how your game will play. Now find a table someplace comfortable and put in front of you the notes you have taken on game concept, business context, and the feature questions asked above. Then I want you to put this book aside and just keep visualizing your game. Get up and take a walk, get something to eat, and come back to your table of notes. Now, start slicing out the parts of your game feature brainstorm that are not actually central to your game design. Before you invest in creating a hundred-page game design document and develop a total technical design, you should figure out what you are making. The game design and technical design stages are a lot of work; be courageous and kill the features that are superfluous before you spend any more effort on them. All of the great games have a small feature set that is well polished. Make your game great. Chapter 8: Game Design Document 101 Chapter 8 > > > > > > > > > > > > > > > > Game Design Document What Is a Game Design Document and What Does It Do? When one says “Look it up in the design document,” folks are generally referring to the game design document. This is the fun document that details all of the characters, the levels, the game mechanics, the views, the menus, and so on—in short, the game. The game design document for most designers is great fun; here they get to flesh out their vision with muscles and sinew on top of the skeleton of the game concept that it was before. By no means am I saying it is easy to create a complete design document. Creating a finished design document is so difficult I have never been able to finish one of my own, nor have I seen anyone else finish his or her design documents. With my two latest projects, Starfleet Command: The Next Generation for Activision and Black9, I am certainly taking the design efforts to our highest levels, and I see the results paying off with faster and stronger production. The game design document is part of a suite of documents that specify the game you are creating. All of these Where the game design document lies in the project life cycle 102 Chapter 8: Game Design Document documents I collectively call the production plan: n Concept/Vision/Proposal Document n Game Design Document n Art Design Document n Technical Design Document n Project Schedule n Software Testing Plan n Risk Mitigation Plan The components of the production plan The purpose of creating all of these documents is to know what we are going to do. To figure out what we are going to do, we need to do a bunch of thinking. Writing down what we have thought about in the form of diagrams and notes forces us to drive the quality and quantity of thinking to the required level for making a production plan. Knowing what we are going to do will help us answer a great deal more planning questions: Who is going to do them? How long will it take? What needs to be done prior to getting that done? What features do we need to cut to give us time to do that? What are the risks in this project? This is all the most basic stuff to kick off a software development project to reassure each other we know what we are doing, and incidentally most good publishers require this planning. This chapter will focus on the game design portion of the production plan. There are several good books on the market that discuss game design in particular. This book aims to cover new ground by discussing game production and development as a whole of which game design is a subtask in this greater effort. What I will not do is design your game for you. I will not be offering opinions on whether your game should be multiplayer or 3D or online or all three. I have neither the inclination nor the hubris to make a book offering such suggestions. I am merely presenting a rigorous and systematic approach to game design you might apply to your own creative vision. What About the Proposal Document? An observant reader will notice that I have omitted a formal discussion of what should go into your proposal document, which you would show publishers in order to receive funding. A few years ago established developers could write up five to ten pages of game vision and accompany it with some sketches and likely receive funding if a publisher believed in the concept. As Chapter 8: Game Design Document 103 time passes, the competition gets stronger and the games themselves are larger in scope and require deeper talent and skill to execute competitively. The publishers are now expecting to see a playable prototype of your game demonstrating all the talents your team is bringing to the table from programming, art, and design to sound and animation. I am not suggesting that you will not need a vision document or a proposal to pass around; you will need one to sell your game after you have a playable prototype to demonstrate. The downside of this trend is that the development house has to shoulder a larger portion of the financial risk of the project by performing the early financing for the project. This in turn leads to only the stronger, more willful developers being able to develop original content—the holy grail of all developers across the land. I am suggesting specifically that you go ahead and create the first draft of your game design document before you create your proposal. There are a few reasons for this: First you still don’t really know your game, so if you take the time to create a first draft of your game design document, you will create a much stronger vision document and proposal. When you take the game concept in your mind and first try to lay out a proposal, you will find a need to use vague language in parts (or just outright guesses) to describe your game. But if you have your game design document in your hands, you will be able to write a tight proposal. When Do You Write the Game Design Document? You should write your first draft of the game design document immediately after narrowing down your key design concepts from the preceding chapter. However, as I will show you, the game design document is a large undertaking itself in the breadth of topics to be detailed. You might be reading this book from a variety of different perspectives: as a producer or project leader or holding some other position in the industry or looking to get into the industry. If you already have a team of folks to work on this game with you, I encourage you to distribute and delegate portions of the game design document to your team. This is somewhat controversial, and I am sure a good many of my peers would disagree and feel more comfortable with a strong designer at the helm of the ship articulating the game’s design from a single, focused mind. I do agree that you need to have a visionary who has ultimate ownership of the game’s design and who holds executive control, but I advocate judiciously distributing some of the more modular, more straightforward tasks to other team members. Or at least provide textual or visual sketches and allow others to elaborate on your designs. The reason for this delegation is twofold: One, creating a game design document is so much work that it is natural to break the job up across multiple people to get the work done more rapidly and with higher quality. My other justification for this delegation is that this is one of the effective ways 104 Chapter 8: Game Design Document because many of your team members may be new to game design or lack the creative initiative that your designer self has. After all, that is why you are leading the production plan. If you lay out what they need to write up, specify what diagrams they need to create and what their text needs to discuss, and provide a template, they will not feel frustrated but will feel empowered in contributing to the project in the early stages. This will help them understand that their role is important and create a feeling of project stakeholder in the team member. Again, I have never seen a completed design document, and one of the reasons is that game design documents need to be maintained through the course of production. With every game developer wishing they had just another few weeks to add this bit of polish to their games, it would be logical to think that every game design document could have added a bit more detail here or clarification there. In the end, you should measure the completeness of your game design document by how well the team was led by the game design. How much confusion or lost work was created by a lack of detail or clarity in the document? How much reworking of the gameplay had to be performed in the course of production due to ill-thought-out designs? These are the questions you should ask yourGame design activity is always happening. self in the postpartum stage of your game’s cycle. Take the time to review your game To delegate design tasks well, be sure design document at the beginning of to take the time to clearly describe to each milestone to be sure your develyour teammates what topics you need opers have ready the most accurate and them to design and provide a style up-to-date reflection of the game’s guide or template that you require the work delivered under. This is important design before they commence that you can build a strongly bound, effective team for your project. They will not be able to disengage from the project easily if it is their ideas and plans that make up the project. Chapter 8: Game Design Document 105 milestone’s work. Also look farther into groundwork for elements of the game the future to document design changes no longer needed even if they are so that your developers do not lay the beyond the current milestone. What Should Go into a Game Design Document? Game design documents are more akin to business plans than blueprints for a building or a mechanical engineering diagram in that the industry has developed no standardized formal requirements for a game design document. This is part of the lack of development discipline and rigor that is pervasive throughout the software industry. Games used to be so much smaller in scope and complexity that it was much simpler to document the game design, so no great amount of formalism was required. The movie industry has settled down to such a degree that there are hundreds of universities and colleges that offer specific courses on how to write a movie script. The game industry grosses more revenue than Hollywood does at the box office, yet just a few pioneering universities and colleges are offering classes on game programming and art for new media. I know of no class that teaches game design. Thus, we are just too young an industry and our technology is changing too rapidly for us to settle on the requirements of a game design document. Another complication is that all of us get our starts on smaller projects or conversion work where the demand for a detailed design document is substantially lower, robbing us of an opportunity to grow our game design skills before we reach the Big Project. What am I going to do about this lack of a game design document standard? I am sharing my game design requirements as well as providing information from other development houses illustrating what we are doing in the field and what we are looking for in a game design document. A happy, productive game developer backed up with strong designs The game design document should describe to all the team members the functional requirements of the features they are implementing for the project. The ideal game design document is complete and has seen revisions to fix gameplay and add clarity. In theory the game developers should be able to take their copy of the game design document and run with it. In practice it is very difficult to create a document that strong. 106 Chapter 8: Game Design Document Section One: Defining the Game many times to tolerate their time being frittered away, and they demand a I will discuss the content of the game design document by using sections; the strong and clear vision for the game. Every game design document order of the sections was chosen to should have a section at the front that lead the reader from general informaclearly describes to the reader what the tion concerning the project at large game is. It should be written so clearly towards the details of the project that are specific to only certain members of and succinctly that it does not leave any vagueness in the reader’s mind what the development team. the game is about. It should describe the world, the gameplay, and what motiArticulate What the Game Is as Clearly as Possible vates the player. Following are a couple I remember reading the postmortem of of examples. Pac-Man: An arcade game featuring Tropico in Game Developer magazine. I a single joystick for controls where the really appreciate reading postmortems player directs the protagonist, Pac-Man, of game projects, and I am always to clear levels of mazes of dots by eatgrateful to the developers who have ing these dots. The enemies of our the courage to document what they did wrong and what they did right. The hero are four cute pastel-colored ghosts that will eat our hero unless our hero is most amazing thing I read in the Tropico design document is that after a under the influence of the big power-up year of development the team came to dot. Doom: A first-person shooter the shocking realization that there were played on the PC platform, where the about half a dozen different visions of player controls a space marine in a 3D Tropico being developed by various environment against a horde of bizarre team members. Each team member monsters. The player has a configwas implementing his or her own urable set of controls taking advantage version of the project! I was first of the keyboard, mouse, or joystick. shocked to hear that something like The gameplay is action based with no that could happen; I was then shocked strategic or role-playing elements; to read that the team had the courage instead the game depends on bleeding to document it and share it with the industry. Then I thought about it more edge technology providing a rush of carefully, and I realized that every game adrenaline through its aggressive attention to carnage. Single-player mode will project has the potential to splinter off provide three episodes of missions into separate projects and that many against an increasingly horrible cast of other projects have suffered from the monsters and scary settings; the same lack of central vision. I believe multiplayer mode will feature an this is why so many developers advocate a strong lead designer who dictates unprecedented level of player-to-player combat. all decisions from art to dialogue to From my own experience I know placement of buttons on the screen. there are many personalities in the Experienced developers have been game business; some personalities burned by design-by-committee too belong to wonderful human beings you Chapter 8: Game Design Document 107 want to spend a bunch of time with; other personalities are less inviting. I think a lot of projects suffer when the leaders of the projects choose to practice conflict avoidance. I would hazard a bet that members of the Tropico team sensed they were working towards different goals yet decided not to rock the boat either in an effort to create a more pleasant workplace or to selfishly give their own version of the game more time to grow (perhaps to a level of commitment where it could not be cut back). This is an area I find particularly hard to manage. I think my teammates would be surprised to hear me say that. They would probably say I lead the team well and with strength. However, I must confess there are only a few things in life I like to do less than to cut off the design direction of one of my team members. This is because while I believe a game project needs executive direction, I also believe the best games are made when everyone’s energies are woven into a stronger whole than any individual can deliver. Therefore my advice is to take the time to write up exactly what your game is and present it to your team members as early as possible. If you know one of your team members despises real-time strategy games, but you are committed to creating a real-time strategy game, no good can come out of misleading him—tell the truth straight up. He will either do his best to create the best real-time strategy game he can or move on to another project that fits his interest. But by no means would it be a good idea to keep investing in a team member making role-playing features that you cannot use. When it comes time to cut those features out, you will have a genuinely pissed off person and a confused team. Set the Mood When the game is so clinically described as I advocate above, often the soul of the game is lost in the translation. Many games are role-playing games set in a fantasy world. This does not mean that Ultima, Bard’s Tale, Baldur’s Gate, and Pool Radiance are the same game. I like to see a short piece of fiction at the opening of a game design document to quickly give me the feel for this world, to put me in the mood. The intro movie in a released game has the same function: to introduce the player to what sort of challenges the game holds. Some games do not lend themselves well to a fiction treatment, such as the abstract puzzle and classic arcade games of Pac-Man, Frogger, and Tetris. Even so, a snippet of words from an auto-racing television commentary intermixed with entries in a racecar drivers’ journal discussing the upgrades he has performed on his car and how desperately he needs to win this race to pay his debts would quickly draw me into the world of Gran Turismo. Section Two: Core Gameplay Now we move quickly from general statements about the game to direct comments about the core gameplay. We want to fix in the reader’s mind the vision and feel for the gameplay early on so that when he digests the rest of the document it will be in relation to the core gameplay and create a tighter understanding of the game design. 108 Chapter 8: Game Design Document The Main Game View The Controller Diagram TE Some games have only one view of the game; others have several view modes or even different levels of gameplay with different views. This chapter in the game design document needs to define the main game view of the game. Is it a 3D view? 2D? Isometric? If it is isometric, what is the scale of the tiles and characters? If it is a 3D view, what kind of 3D view? Is it an interior engine type game, or do you require exterior environments? If it is an exterior engine, how far does the view need to extend? Is it primarily rendering hills and trees or is it rendering a racetrack or a city? Make a few sketches of the view, or even better get an artist on your team to make a full-color mockup of the view. MUST DO!—The main game view of the project must be in every game design document and quickly convey to the reader what the game will look like. A critical diagram to create is the controller diagram. This diagram shows at a glance how the game inputs are mapped to a game pad controller or a keyboard. Core Player Activity What does the player do in this game? What is the key interaction? Pilot a starship? Drive a racecar? Organize an army? Maneuver a character through a 3D space? This is where you detail the key interactions between the player and the game. Together with the main view from above the reader will develop a strong understanding of the game you are creating. This is an excellent place to use the UML use case diagrams introduced in the previous chapter to document the interactions between the player and the game. Create the UML diagrams that organize these interactions in a graphical manner for easy digestion on the reader’s part. AM FL Y Team-Fly® The controller layout for Taldren’s upcoming game Black9 In-Game User Interface Working outward from the view and the core activities, what are the other user interface items visible on the main display? Health? Time? Mana? Distance to target? Radar? Map? Now is the time to detail the rest of these user interface items to be found on the main display. Take the time to create a diagram or mockup for each of these display items and update your use case hierarchy to track these interactions (even if they are a non-interactive display, the player uses these items by viewing them). An early preproduction view of the Black9 main interface Chapter 8: Game Design Document 109 Section Three: Contextual Gameplay This will be a fairly meaty section. In this part of the game design document you will detail all the rest of the game mechanics that were too deep to discuss in the core gameplay section. The Nuts and Bolts of Game Mechanics Now is the time to talk about how much horsepower that engine will develop, how many marines that transporter can transport simultaneously, how many charges are in your magic wands, how fast the characters move. Detail everyShell Menus thing you can of the game mechanics. I find it useful to pretend I am creating a Most games on both the consoles and pen and paper role-playing game or the PC have shell menus for creating board game complete with all the characters, upgrading cars, reviewing inventory, selecting spells, viewing how details. Of course all these elements will need to be tweaked and balanced in many stars or crystals have been colthe future; however, every time I drive lected, and so on. Now is the time to down to this level of detail I learn more create a mockup of the shell menus complete with all the displays and but- about my game at the higher levels of abstraction and go back and adjust eletons. We have found it particularly useful to create UML use case text and ments of the higher design. This section should be replete with spreaddiagrams for all the shell menu activities the player can go through. It is also sheets, charts, and diagrams. important to create a menu flow map Tutorial Mechanics showing the relationship between all Almost all big games have integrated the menus—how the player may navigate between the activities in the game. interactive tutorials in the game. Some The menu flow for Black9 110 Chapter 8: Game Design Document of these tutorials are explicitly tutorials, others are billed as licenses as in Gran Turismo, and other games simply create very easy levels for the beginning of the game like in Mario64. For Starfleet Command: The Next Generation, we modeled the tutorials around the education an officer in Starfleet would receive while going through Starfleet Academy. Discuss your philosophy when approaching the tutorial content, discuss what you want the player to learn here, and discuss what activities you will employ to reinforce what the player is taught to make for a smooth transition into actual gameplay. In Baldur’s Gate, BioWare had the player character start out in a safe town where all of the NPCs acted partly as an interactive in-game manual and also related backstory to the players to get them into the world. How are you going to introduce your player to the game? Consciously decide what controls and game mechanics you are going to directly cover in your tutorials and what material you are leaving for the player to learn over time as they master the game. Keep in mind the goal of the tutorial is not to teach everything in the game; rather the purpose of the tutorial is to get the player into playing the game successfully and without frustration as quickly as possible. course you have a multiplayer feature set to document. If you did not cover your multiplayer menus in the shell menu section, then this is the perfect place to detail the activity flow between the menus. Write down the functionality of each of the buttons and describe the player’s choices. Also detail the technical requirements of the multiplayer feature set that the technical design will need to address. How many players will your game support? Are these players simultaneous, concurrent players as in a Quake game? Or are the players residing in a hybrid system like Starfleet Command’s online campaign that is capable of supporting hundreds of simultaneous players where the battles are played out in smaller sessions of up to six players each? Create diagrams documenting these activity flows. Will your game support the historic modes of multiplayer such as serial, modem-tomodem, or even hot seat? With the latest generation of consoles starting with SEGA’s Dreamcast and on through Sony’s PS2 and Microsoft’s Xbox, the game designer now needs to consider online multiplayer gaming for their console games. On the console side, multiplayer games have often used multiple controllers. Will your console game have multiplayer Multiplayer Mechanics gameplay? Will you split the screen? Will your game have a multiplayer com- Will you hot seat between players? Many game designers put off ponent? If so, what flavor? Will you describing their multiplayer gameplay support LAN play for PC games in the office or home LAN environment? Per- until later in the project. This has led to disastrous delays, poor gameplay and haps you will feature online matching game balance, and outright bugginess. via GameSpy or Microsoft’s Gaming This procrastination in multiplayer Zone. If your game is a massively game design is fairly widespread and multiplayer role-playing game, then of carries down the line, with the Chapter 8: Game Design Document 111 The menu flow diagram for Starfleet Command 3 technical design stage often postponing a serious discussion of the multiplayer engineering requirements. Sometimes these delays are so manifest, games have resorted to the outright outsourcing of the multiplayer project. Examples of this are Interplay’s Klingon Academy and id’s Return to Castle Wolfenstein, where Grey Matter develops the single-player game and another developer will come along behind and implement the multiplayer aspect of the game. I am highly skeptical of outsourced game creation in a piecemeal fashion. The only reason people delay thinking about their multiplayer feature set is because it is hard. But being hard is not a good enough reason for putting it off! Section Four: Talk Story This section of the game design document calls for the game designer to elaborate on the world they have created. Many game developers would really rather work on this part of the game design document than discuss the mundane buttons on the multiplayer screens. The reason I have pushed this section back as far as I did is because I feel the game design document should serve the team rather than the designer. So I started with setting the mood and quickly followed with capturing the key requirements of the game. Now let’s roll out the graph paper, character sheets, and scripts for the cut scenes! 112 Chapter 8: Game Design Document World Backstory Character Backgrounds The character background section is also game dependent. All games have characters; it is just the concept of what a character might be that is stretched a bit in some genres. For example, role-playing games, actionadventure, and platformers would all have a section that is quite straightforward in its representation of characters, with sketches of how they look and text describing their behavior and attitude in the game. Include all of the game mechanics stats that correspond to this character such as attributes and inventory. Include references to where in the game the character will be found and indicate what type of character this A fan-made map of Britannia from the Ultima series is: protagonist, playable, non-player, antagonist, or boss monster. Detail your world; what is the relevant In the case of Gran Turismo I history of the world? Draw a map of the would argue that the individual cars are world the player will explore. Use cool the characters, especially unique cars maps for fantasy games such as like the Suzuki Escudo. Here the stats Baldur’s Gate and Ultima Online, but behind the cars and the history of the also include ship blueprints for games creation serve as the backstory. In a like System Shock 2, or the oceans of real-time strategy game each of the the world for a naval simulation. The individual combat units is a character to depth of this section is highly dependbe detailed. For a real-time tactical ent on the genre of your game. id game like Starfleet Command: The Software is very proud that their Doom Next Generation, we actually have and Quake series of games have no three different classes of “characters” need for such frills as a backstory! that are quite different from each other, Ultima Online and Baldur’s Gate each but all need to be detailed. These three draw upon decades of development for character types are the classic charactheir world’s backstory. ters to be found in the story, the ships A game such as Gran Turismo the player will command or interact would only need the lightest treatment with, and the ship officers that the of a backstory where the racing events, player will recruit and train in the the tracks, and the manufacturers of course of their career. cars would be enumerated to flesh out the scope of the world’s backstory. Chapter 8: Game Design Document 113 A character concept for Black9 Level, Mission, and Area Design This is my favorite part of writing a game design document. I love examining and reading maps! Most likely your game is broken down into levels, missions, areas, tracks, episodes, decks of a ship, or some other manner of location partition. In abstract games like Lemmings, the levels are single screens of challenge for the Lemmings; for Gran Turismo it is the different tracks of course; for Doom it is bizarre and frightening levels that the designers come up with in a backstory after they have made them. To document a level you have to take into account what sort of game you are making and how it is broken up. For classic role-playing games, largescale fantasy maps of the countryside with detailed blueprints scaled to tenfoot corridors serve very well. For 3D games, whether platformer, shooter, or action-adventure, it can be very challenging for the designer to specify the level in detail. The reason is that the designer may be a good designer but terrible in the use of a 3D CAD tool such as UnrealEdit or WorldEdit. Often these types of games employ a lead designer who is good with these tools and can articulate her visions directly in the tools. For the developer without these skills, very detailed writing as found in a narrative supplemented with sketches will often serve to give the level designer a strong description to work with. Be sure to give good detail: Talk about the colors, the textures, the lighting, what the sky looks like. What are the sounds that are present in this area? What are the characters? Detail each trick, trap, challenge, or feature in your level design. On your first few passes through here, just make notes to yourself to follow up later and add more detail in the next pass. This is the time to explain your campaign structure; show a flow diagram that relates your areas to each other. Is it linear? That is, can the A view of a level in production for Black9 114 Chapter 8: Game Design Document player proceed through your levels along only one path like the increasingly challenging levels of Lemmings, or can the player wander about without any direct purpose as in Ultima Online? Be sure to diagram this flow. Declare the purpose of the area; is it a key hub area that the player will visit often or is it a bonus area or is it a part of the user interface such as the difficulty selection of Quake I? Discuss how this level may be reused like the reversing of tracks in Gran Turismo or going back for six stars in each of the worlds of Mario64. The storyboard is a key frame-byframe visual design of the cut scenes that reads much like a comic strip. This is a critical design document for both communicating with the artists who will create the level and for achieving buy-in from the project stakeholders. The script should follow standard movie script formatting guidelines. See the following script excerpt for an example of how to format your script for voice-over (VO) and off-stage (OS) voice work. With this section complete, no reader should have any large questions or vagueness about the world and cast Cut Scene Descriptions of characters in your game design. The reader should also have a strong underIf your movie will employ cut scenes, standing of what challenges the players then write the scripts for these cut scenes. While the game industry has no will face as they proceed through the standard format for the description of a game structure. cut scene, there are two important components: a storyboard and a script. INT. MISSION BRIEFING ROOM (GENESIS HQ-LAX) Set in the mission briefing room of the Genesis Operations Headquarters in the LAX spaceport metroplex. The mission briefing is a short cinematic sequence performed in letterbox format using the in-game Matinee feature of the Unreal engine. The briefing room has four characters: the player character, the Genesis Operations Chief, and two other contract Genesis agents, one large, physically powerful male and one slim female. GENESIS OPERATIONS CHIEF (VO) We have a very serious development with our secure AI labs on the moon. We have had no communication from the base personnel in 36 hours. While the computer network seems to be functional, we have lost access to the data arrays—somebody has changed the authorization code. Fly-bys show no actual damage to the structures and we have sent two regular patrols from Luna II—they have failed to report in after reaching the lab. (beat) It appears that The Tea-Drinking Society is getting desperate now that we are so close to our goal; they must have launched an assault on the lab and taken physical control—now they’re busy downloading all of our hard-earned work. Your mission is to reclaim our labs and eliminate any hostiles that may be present. You have two support operatives this time. The Chief gestures towards a slim female in black super-hero spandex GENESIS OPERATIONS CHIEF (VO) Cassandra will provide you with infiltration and electronic hacking services. Her job is to get the team in there as quietly as possible. The goal is to catch The Tea-Drinking Society in the act, get it on film, and eliminate the suspected TDS agents before they are able to return to their masters with the fruits of our lab work! Nodding towards a bulky male human with obviously large guns Chapter 8: Game Design Document 115 GENESIS OPERATIONS CHIEF (VO) Rojak is a heavy weapons specialist. He’ll back you up in a firefight and ensure that anything hostile becomes a detail of history in short order. The Chief points towards the player character GENESIS OPERATIONS CHIEF (VO) As our most celebrated agent, you’re in charge. Make contact after you’ve landed and entered the base. PLAYER CHARACTER (VO) “Thank you, sir. We will not let you down.” Cinematic fades to black, the sound of rocket engines throttle up out of the darkness… A snippet of a design document of Black9 featuring a cinematic sequence Section Five: Cover Your Assets eye-pleasing pixels. Write up the list This section’s format really is particular of such assets in a spreadsheet and include columns for attributes that are to your game’s genre and method of specific to your game’s design and construction. This last point is so technical requirements. important I would recommend not creating asset lists until you are mostly through the technical design stage. You should certainly jot down the assets that come to mind in each section at the end of your first pass on the game design document; however, your technical design document might reveal that on the platform of your choice and with your particular set of requireA character model in production from Black9 ments, you are limited to the creation of just 20 character models rather than Missions, Levels, or Areas the 100 your initial design called for. Or List the missions, levels, or areas to be you might find that the technical format created for your game. Indicate gameand specification of your assets goes specific parameters such as size, priorthrough some bit of exploration during ity, or placement in a hierarchy of the elaboration of your game in the locales. technical design stage. Nevertheless, here are some categories of assets you should list in your game design document. These lists will come in handy when creating the production plan, which should be created after the technical design stage has been mostly completed. 2D Sprites or 3D Models Whatever your technology, no doubt your game features moving bits of The city of Baldur’s Gate 116 Chapter 8: Game Design Document Voice It will be way too early to document this section in the early phases of game design; however, strong description of the voice actors required can certainly be detailed early in the project. As production rolls along, maintain this section to prevent a panic workload when it comes time to record the voice. Command 190: Basic Controls Setting: The Neversail NCC-0001 at Treasure Island, San Francisco, Earth · · · · Helm Target Phaser Fire (somehow have plenty of phasers to fire) Destroy Cargo Boxes Title: Command 190: Basic Controls Briefing: This simulation will cover the basic controls of a starship. Setting Text 1: Aboard the Neversail NCC-0001 Setting Text 2: Starfleet Academy, Home Fleet Setting Text 3: Treasure Island, San Francisco, Earth {The Neversail NCC-0001 is a police frigate armed with only Phaser-3s} {The screen is already set in full screen mode} {There is no terrain, only a beautiful backdrop} {The player’s ship is already in motion at a speed of 10} {The player’s ship is already at Red Alert} {VOICE TALENT: FED-INSTRUCTOR-EARTH: Scotty? Not Sulu – we will save him for later tutorials.} FED-INSTRUCTOR-EARTH: “Lieutenant, welcome to Starfleet Command school. To earn the rank of Lieutenant Commander, you must pass both Command 190: Basic Controls and Command 290: Intermediate Helm Controls. Let’s get started.” FED-INSTRUCTOR-EARTH: “The basics of starship control are very simple, yet require a lot of training and practice to master. Let’s begin with basic helm control aboard a small police vessel, the USS Neversail.” FED-INSTRUCTOR-EARTH: “To turn the Neversail, use the mouse and left-click on the 3D tactical display. This will issue a helm command to port or starboard.” FED-INSTRUCTOR-EARTH: “Left-click on the 3D tactical display in the direction you wish to turn. Your helmsman will choose the appropriate turn, port or starboard.” {Wait for the user to turn the ship. Add sarcastic/encouraging comments to the player to hurry them along.} Sarcastic Comments FED-INSTRUCTOR-EARTH: “Well Lieutenant, what are you waiting for? A Klingon invasion?” FED-INSTRUCTOR-EARTH: “Lieutenant, when I give an order I expect it to be obeyed.” FED-INSTRUCTOR-EARTH: “I don't have all day, Lieutenant.” FED-INSTRUCTOR-EARTH: “[Sigh]. We are all waiting.” FED-INSTRUCTOR-EARTH: “Lieutenant, make up your mind before I make it up for you – and give you a failing grade.” Chapter 8: Game Design Document 117 Positive Remarks FED-INSTRUCTOR-EARTH: “Very good, Lieutenant.” {Add 1 prestige point for each helm command up to 3 points} FED-INSTRUCTOR-EARTH: “The farther you wish to go from your current heading, the tighter your turn will be. Starships are massive vessels, even one such as this quaint police cutter. It takes time to maneuver them. Plan your turns in advance for maximum advantage.” FED-INSTRUCTOR-EARTH: “Now let’s talk about phasers. I knew that would pique your interest. To familiarize you with the trustworthy phasers, I have created replicas of standard Federation cargo containers for you to target and destroy.” FED-INSTRUCTOR-EARTH: “To target a container, point the mouse at the container that you wish to target and right-click. This will set the cargo container as your current target. Alternatively you may tap the T key to cycle through all targets in sensor range.” {Add 1 prestige point for each targeting command up to 3 points} {Wait for the user to target a container. Add sarcastic/encouraging comments to the player to hurry them along.} Sarcastic Comments FED-INSTRUCTOR-EARTH: “C’mon, Lieutenant. It doesn’t take that long to target a container.” {Default the weapons to 1 at a time firing} FED-INSTRUCTOR-EARTH: “To fire a Phaser-3 at the selected cargo container, left-click your mouse on the fire button in the lower left corner of the display. Alternatively, you can tap the Z key to issue a fire command. Either one will direct gigawatts of ionized superheated particles at your target. Sounds impressive.” FED-INSTRUCTOR-EARTH: “Now destroy all three targets.” {Wait for the user to fire upon a container. Add sarcastic/encouraging comments to the player to hurry them along.} Sarcastic Comments FED-INSTRUCTOR-EARTH: “What’s keeping you? Most midshipmen enjoy this part of the tutorial.” Encouraging Comments (when container destroyed) FED-INSTRUCTOR-EARTH: “There she goes!” FED-INSTRUCTOR-EARTH: “Good! Starfleet doesn’t approve of mindless destruction, but phasers do have their uses.” {Add 2 prestige points for each container destroyed up to 6 points} FED-INSTRUCTOR-EARTH: “Excellent, Lieutenant, you are coming along very well. Perhaps Command 290 will provide a greater challenge for your abilities.” A shooting script for Starfleet Command 3 List your characters and the required If your game features human characters moves for each character. Maintain this list during production. See the followmoving about, then you might require ing example. motion capture or you can use key framing to animate your characters. Key Framing and Motion Capture 118 Chapter 8: Game Design Document Sample Shot List Confidential Scene# 1 filename "A1-walk-idle" performer character "assassin" concatenated capture description (we place a formula here which "concatenates" all your detailed info into one item) client moves description "Assassin looks around, standing in place." Loop to be shot for looping (blending) in post TrackProp "rifle" 2 "A1-walk-idle-fire" "assassin" "Assassin fires assault rifle straight ahead from standing position." "Assassin walks forward carrying assault rifle." "Assassin walks forward firing assault rifle." "Assassin walks backward carrying assault rifle." "Assassin walks backward firing assault rifle." "Assassin sidesteps to the left carrying assault rifle." "Assassin sidesteps to the left firing assault rifle straight ahead." "Assassin sidesteps to the right carrying assault rifle." "Assassin sidesteps to the right firing assault rifle straight ahead." "Assassin turns in place carrying rifle." "Assassin turns in place firing rifle." "Assassin looks around, standing in place, heavy breathing, excited." "Assassin fires assault rifle straight ahead from standing position, heavy breathing, excited." "Assassin runs forward carrying assault rifle." "Assassin runs forward firing assault rifle." "Assassin runs forward carrying assault rifle, hurdling low obstacle." "Assassin runs forward firing assault rifle, hurdling low obstacle." "Assassin runs backward carrying assault rifle." "Assassin runs backward firing assault rifle." "Assassin sidesteps quickly to the left carrying assault rifle." "Assassin sidesteps quickly to the left firing assault rifle straight ahead." "Assassin sidesteps quickly to the right carrying assault rifle." "Assassin sidesteps quickly to the right firing assault rifle straight ahead." "Assassin looks around cautiously on balls of feet, standing in place." "Assassin fires assault rifle straight ahead from standing position." "Assassin sneaks forward carrying assault rifle." "Assassin sneaks forward firing assault rifle." to be shot for looping (blending) in post to be shot for looping (blending) in post to be shot for looping (blending) in post to be shot for looping (blending) in post to be shot for looping (blending) in post to be shot for looping (blending) in post to be shot for looping (blending) in post to be shot for looping (blending) in post to be shot for looping (blending) in post to be shot for looping (blending) in post to be shot for looping (blending) in post to be shot for looping (blending) in post to be shot for looping (blending) in post "rifle" 3 4 5 6 7 8 "A1-walk-forward" "A1-walk-forward-fire" "A1-walk-backward" "A1-walk-backward-fire" "A1-walk-step-left" "A1-walk-step-left-fire" "assassin" "assassin" "assassin" "assassin" "assassin" "assassin" "rifle" "rifle" "rifle" "rifle" "rifle" "rifle" 9 10 "A1-walk-step-right" "A1-walk-step-right-fire" "assassin" "assassin" AM FL Y Team-Fly® "rifle" "rifle" 11 12 13 "A1-walk-turn" "A1-walk-turn-fire" "A1-run-idle" "assassin" "assassin" "rifle" "rifle" "rifle" TE "assassin" 14 "A1-run-idle-fire" "assassin" "rifle" 15 16 17 "A1-run-forward" "A1-run-forward-fire" "A1-run-forward-hurdle" "assassin" "assassin" "assassin" to be shot for looping (blending) in post to be shot for looping (blending) in post to be shot for looping (blending) in post to be shot for looping (blending) in post to be shot for looping (blending) in post to be shot for looping (blending) in post to be shot for looping (blending) in post to be shot for looping (blending) in post to be shot for looping (blending) in post to be shot for looping (blending) in post to be shot for looping (blending) in post to be shot for looping (blending) in post to be shot for looping (blending) in post to be shot for looping (blending) in post "rifle" "rifle" "rifle" 18 "A1-run-forward-hurdle-fire" "assassin" "rifle" 19 20 21 22 "A1-run-backward" "A1-run-backward-fire" "A1-run-step-left" "A1-run-step-left-fire" "assassin" "assassin" "assassin" "assassin" "rifle" "rifle" "rifle" "rifle" 23 24 "A1-run-step-right" "A1-run-step-right-fire" "assassin" "assassin" "rifle" "rifle" 25 "A1-sneak-idle" "assassin" "rifle" 26 "A1-sneak-idle-fire" "assassin" "rifle" 27 28 "A1-sneak-forward" "A1-sneak-forward-fire" "assassin" "assassin" "rifle" "rifle" Chapter 8: Game Design Document 119 29 30 31 "A1-sneak-backward" "A1-sneak-backward-fire" "A1-sneak-step-left" "assassin" "assassin" "assassin" "Assassin sneaks backward carrying assault rifle." "Assassin sneaks backward firing assault rifle." "Assassin gingerly sidesteps to the left carrying assault rifle." "Assassin gingerly sidesteps to the left firing assault rifle straight ahead." "Assassin gingerly sidesteps to the right carrying assault rifle." "Assassin gingerly sidesteps to the right firing assault rifle straight ahead." "Assassin turns in place with soft steps carrying rifle." "Assassin turns in place with soft steps firing rifle." "Assassin looks around, crouching in place." "Assassin fires assault rifle straight ahead from crouching position." "Assassin walks forward crouching and carrying assault rifle." "Assassin walks forward crouching and firing assault rifle." "Assassin walks backward crouching and carrying assault rifle." "Assassin walks backward crouching and firing assault rifle." "Assassin sidesteps to the left crouching and carrying assault rifle." "Assassin sidesteps to the left crouching and firing assault rifle straight ahead." "Assassin sidesteps to the right crouching and carrying assault rifle." "Assassin sidesteps to the right crouching and firing assault rifle straight ahead." "Assassin turns in place crouching and carrying rifle." "Assassin turns in place crouching and firing rifle." "Assassin jumps straight up, carrying rifle." "Assassin jumps straight up, firing rifle." "Assassin leaps forward carrying assault rifle." "Assassin leaps forward firing assault rifle." "Assassin jumps backward carrying assault rifle." "Assassin jumps backward firing assault rifle." "Assassin lunges to the left carrying assault rifle." "Assassin lunges to the left firing assault rifle straight ahead." "Assassin lunges to the right carrying assault rifle." "Assassin lunges to the right firing assault rifle straight ahead." to be shot for looping (blending) in post to be shot for looping (blending) in post to be shot for looping (blending) in post to be shot for looping (blending) in post to be shot for looping (blending) in post to be shot for looping (blending) in post to be shot for looping (blending) in post to be shot for looping (blending) in post to be shot for looping (blending) in post to be shot for looping (blending) in post to be shot for looping (blending) in post to be shot for looping (blending) in post to be shot for looping (blending) in post to be shot for looping (blending) in post to be shot for looping (blending) in post to be shot for looping (blending) in post to be shot for looping (blending) in post to be shot for looping (blending) in post to be shot for looping (blending) in post to be shot for looping (blending) in post to be shot for looping (blending) in post to be shot for looping (blending) in post to be shot for looping (blending) in post to be shot for looping (blending) in post to be shot for looping (blending) in post to be shot for looping (blending) in post to be shot for looping (blending) in post to be shot for looping (blending) in post to be shot for looping (blending) in post to be shot for looping (blending) in post "rifle" "rifle" "rifle" 32 "A1-sneak-step-left-fire" "assassin" "rifle" 33 "A1-sneak-step-right" "assassin" "rifle" 34 "A1-sneak-step-right-fire" "assassin" "rifle" 35 36 37 38 "A1-sneak-turn" "A1-sneak-turn-fire" "A1-crouch-idle" "A1-crouch-idle-fire" "assassin" "assassin" "assassin" "assassin" "rifle" "rifle" "rifle" "rifle" 39 "A1-crouch-forward" "assassin" "rifle" 40 "A1-crouch-forward-fire" "assassin" "rifle" 41 "A1-crouch-backward" "assassin" "rifle" 42 "A1-crouch-backward-fire" "assassin" "rifle" 43 "A1-crouch-step-left" "assassin" "rifle" 44 "A1-crouch-step-left-fire" "assassin" "rifle" 45 "A1-crouch-step-right" "assassin" "rifle" 46 "A1-crouch-step-right-fire" "assassin" "rifle" 47 48 49 50 51 52 53 54 55 56 "A1-crouch-turn" "A1-crouch-turn-fire" "A1-jump-standing" "A1-jump-standing-fire" "A1-jump-forward" "A1-jump-forward-fire" "A1-jump-backward" "A1-jump-backward-fire" "A1-jump-left" "A1-jump-left-fire" "assassin" "assassin" "assassin" "assassin" "assassin" "assassin" "assassin" "assassin" "assassin" "assassin" "rifle" "rifle" "rifle" "rifle" "rifle" "rifle" "rifle" "rifle" "rifle" "rifle" 57 58 "A1-jump-right" "A1-jump-right-fire" "assassin" "assassin" "rifle" "rifle" 120 Chapter 8: Game Design Document 59 "A1-chest-hit" "assassin" "Assassin flinches from shot in chest while carrying assault rifle." "Assassin flinches from shot in chest while firing." "Assassin flinches from shot in stomach while carrying assault rifle." "Assassin flinches from shot in stomach while firing." "Assassin flinches from being shot from the left while carrying assault rifle." "Assassin flinches from being shot from the left while firing." "Assassin flinches from being shot from the right while carrying assault rifle." "Assassin flinches from being shot from the right while firing." "Assassin is knocked down by force from the front while carrying assault rifle." "Assassin is knocked down by force from the front while firing." "Assassin is knocked down by force from the back while carrying assault rifle." "Assassin is knocked down by force from the back while firing." "From knocked down from front position, assassin rolls up and stands carrying rifle." "From knocked down from back position, assassin rolls up and stands carrying rifle." "Assassin activates a wall switch." "Assassin crouches and begins tinkering with gadgetry." "Assassin tinkers with gadgetry." "Assassin stops tinkering and stands." "Assassin presses small object to neck, injecting healing serum." "Assassin picks up an object from table height." "Assassin crouches, picks up an object from the ground, and stands." "Assassin covers face with arm and cowers for 3 - 5 seconds before returning to a normal stance." "Assassin collapses to ground with some impact." "Assassin folds up and slumps to ground." "Assassin has several violent spasms before collapsing to ground." to be shot for looping (blending) in post to be shot for looping (blending) in post to be shot for looping (blending) in post to be shot for looping (blending) in post to be shot for looping (blending) in post to be shot for looping (blending) in post to be shot for looping (blending) in post to be shot for looping (blending) in post to be shot for looping (blending) in post to be shot for looping (blending) in post to be shot for looping (blending) in post to be shot for looping (blending) in post blends from "A1-knockdown-front" blends from "A1-knockdown-back" "rifle" 60 61 "A1-chest-hit-fire" "A1-gut-hit" "assassin" "assassin" "rifle" "rifle" 62 63 "A1-gut-hit-fire" "A1-left-hit" "assassin" "assassin" "rifle" "rifle" 64 65 "A1-left-hit-fire" "A1-right-hit" "assassin" "assassin" "rifle" "rifle" 66 "A1-right-hit-fire" "assassin" "rifle" 67 "A1-knockdown-front" "assassin" "rifle" 68 "A1-knockdown-front-fire" "assassin" "rifle" 69 "A1-knockdown-back" "assassin" "rifle" 70 "A1-knockdown-back-fire" "assassin" "rifle" 71 "A1-roll-stand-front" "assassin" "rifle" 72 "A1-roll-stand-back" "assassin" "rifle" 73 74 75 76 77 "A1-activate" "A1-crouch-tinker-start" "A1-tinker" "A1-crouch-tinker-stop" "A1-use-medkit" "assassin" "assassin" "assassin" "assassin" "assassin" "rifle" blends into "A1-tinker" to be shot for looping (blending) in post blends from "A1-tinker" "rifle" "rifle" "rifle" "rifle" 78 79 "A1-pickup-table" "A1-pickup-floor" "assassin" "assassin" "rifle" "rifle" 80 "A1-stunned-flash" "assassin" "rifle" 81 82 83 "A1-death-falling" "A1-death-slump" "A1-death-spasms" "assassin" "assassin" "assassin" "rifle" "rifle" "rifle" ***NOTE*** Please refrain from punctuation in your moves description and be as specific and brief as possible. The list of moves to be motion captured for Black9 Chapter 8: Game Design Document 121 Sound Effects Music Sound effects are elusive critters to nail down early in the game design document. My best advice is to mentally walk through the mission/level/area section of your game design document and listen to what you hear as you walk through these areas. Almost all games feature music; the only exception I can think of is Quake III, which opted to allow the player to play his or her own favorite music. In this section, list the various tracks you will require to help set the mood of your game. Some games employ sophisticated track blending routines to go smoothly from tense battle music to celebratory victory tunes. See the Black9 audio bid on the following page for an example. Animation Notes Sound Name(keyframe) SFX Notes Attribute Volume 5 Status 1 1 1 1 1 1 1 1 Asset Reference Description Maya Slot Reference Animation Name Nevin Combat Custom 14: Time Dilation Slash 1 15: Time Dilation Slash 2 16: Time Dilation3_ Fierce Slash 17: Time DilationVictory 18: TimeDilationTraverse 19: TimeDilationNormalSpinSlash 20: TimeDilationNormalSpinSlash2 21: TimeDilationThrustySlash 22: TimeDilationChoppyFlipslash 23: TimeDilationTransPos2toPos3 24: TimeDilationTransPos2toPos1 25: TimeDilationTransPos4toPos1 26: TimeDilationTransPos4toPos3 27: TimeDilationVictory Flip timeDilationSlash1 timeDilationSlash2 timeDilationSlash2 timeDilationVictory timeDilationTraverse TimeDilationNewSpinSlash TimeDilationNewSpinSlash timeDilationThrustySlash timeDilationChoppyFlipSlash TimeDilationTrans_Pos2_ to_Pos3 timeDilation_Pos2_to_Pos1 timeDilationTrans_Pos4_to_ Pos1 timeDilationTrans_Pos4_to_ Pos3 timeDilationVictoryFlip TimeDilationVictory2 E3 Victory1 Return Move E3 Attack E3 Attack E3 Attack Final Attack Start Start Start Start SlashSquishDelay1 (5) SlashSquishDelay1 (5) SlashSquishDelay1 (5) SpinSwirl4(3), Landing (17) SpinSwirl3 (2), SlashSquishDelay1(5) SpinSwirl3 (2), SlashSquishDelay1(5) SpinSwirl3 (2), SlashSquishDelay1(5) Stretch4b (1), Stretch4b (1), Stretch4b (1), Stretch4b (1), SpinSwirl3 (6), Landing (19) SpinSwirl3 (3), SpinSwirl2 (5), HardKnock2 (15) 1 thru 8 * 9 thru 18 * 19 thru 27 * SlashChop (2) SlashChop (2) SlashChop (2) SlashHard (1) SlashHard (1) SlashHard (1) ComboLibrary, SwipesSwingV6 Leopard Roar 4, WB03 Combat Flangy swipe 5 5 5 5 5 5 5 5 5 5 5 5 5 1 1 1 2 2 1 28: TimeDilationVictory Spin Attack 0: fastSlashCombo1 1: fastSlashCombo2 2: fastSlashCombo3 3: slowSlashCombo1 4: slowSlashCombo2 5: slowSlashCombo3 basicFast1 basicFast1 basicFast1 basicPower1 basicPower2 basicPower3 5 5 5 5 5 5 3 3 3 3 3 Bad Export The combat sound effects list for the character Nevin from Outrage’s game Alter Echo 122 Chapter 8: Game Design Document Black9 Audio Bid IMPORTANT: PLEASE READ ENTIRE DOCUMENT IN ORDER! Note: The goal of the budget is to come as close to the final product as possible. In a game of this scope it is impossible to know the exact amount of minutes of music. Both parties understand that these figures could change slightly either way but that the figures given should be a very good representation of the budget needed. MUSIC In-Game Music: There are 3 different “worlds” in Black9. The music styles would be representative of those worlds but would follow a sci-fi ambient based vibe (refer to CD). Analog pads, percussion, arpeggiatted synth lines and Enya themed instrumentation will all be used to accomplish our goal. For certain worlds and levels such as China we can incorporate ethnic Asian instruments such as Tibetan Bowls, Java Gamelans, Korean Gongs, Chinese Cymbals, Japanese Kotos and Taiko Drums to give it a certain environmental flavor. Music does not need to be triggered at all times during the game. In fact a lot of the game should be sci-fi environmental location based ambience. “Sci-fi analog action style” music can be triggered when certain key events in each level happen (i.e., Canyon Chase sled escape). Refer to last 2 songs on audio CD called “Wild 9” and “Hover Bikes”. The use of short (3-5 second) musical stings can also be used when certain events happen (i.e., pulls important lever to open important door). There are 3 different “worlds” in Black9. The music styles would be representative of those worlds but would follow an ambient sci-fi feel/vibe. Mars World: 6 search/ambient songs (@ 1:30 minutes = 9 minutes) 4 chase/battle/vehicle songs (@ 1:30 minutes = 6 minutes) 5 stings (@ 5 seconds = 25 seconds) Hong Kong World: 6 search/ambient songs (@ 1:30 minutes = 9 minutes) 4 chase/battle songs (@ 1:30 minutes = 6 minutes) 5 stings (@ 5 seconds = 25 seconds) Moon/Luna World: 4 search/ambient songs (@ 1:30 minutes = 6 minutes) 2 chase/battle songs (@ 1:30 minutes = 3 minutes) 4 stings (@ 5 seconds = 20 seconds) Total In-Game music: Approximately 40 minutes Cinematic Music: Story and cinematics play an important role in Black9. The music for the cinematics should be extremely subtle so that it adds a layer to the dialogue but does not get in its way. There doesn’t have to be music playing during every cinematic and some of the in-game music could be used as well. Mars World: Hong Kong World: Moon/Luna World: 3 songs @ 1 minute = 3 minutes 3 songs @ 1 minute = 3 minutes 2 songs @ 1 minute = 2 minutes Total Cinematic music: 8 minutes Menu Music: There will need to be menu, sub-menu, and credits music. These can be based off of popular motifs we would be creating for the game. Until actual screen interfaces are created it is hard to visualize the style and tempo. Chapter 8: Game Design Document 123 Menu/Sub-Menu theme: 2 minutes Credits music (variation of menu?): 3 minutes Total Menu music: 5 minutes Music Totals In-Game: Cinematics: Menus: TOTAL: 40 minutes 8 minutes 5 minutes 53 minutes (approx.) 53 minutes x $1,000 per minute = $53,000 SOUND DESIGN Sound design will be the most important audio element in the game. In-Game SFX: Big and beefy reverbs, amazing weapons, huge deep doors, frightening alarms, etc. Think of the best sci-fi movie you’ve ever heard… then double it! The main character will have common sounds that will always need to be loaded in memory (footsteps, weapons, getting hit, landing from a jump, etc.). There will be other common sounds as well (pause menu, text messaging, pick-ups, health, etc.) Each of the 16 levels in the game will have unique sound effects for the enemies, vehicles, objects, surfaces, elements, etc. I would average about 50 unique sounds per level considering some of the enemies and weapons will be reused throughout the game. Common sfx: Level sfx: 100 50 X 16 levels = 800 sfx Environmental/Ambient SFX: Strange room tones, machinery, equipment, and generators no one has ever heard before, airy and cosmic tones, deep analog sweeps, dark dramatic atmospheres. Each area may have a different “tone” which when mixed properly gives the sense of travel and exploration. These ambiences should be looping, streamed, and about 1 minute each in length. In some areas you would only hear the ambiences with no music. These are very important! The player will hear these more than they will the music! Ambiences can be reused for multiple areas. If we budget 3 looping ambiences per level we could mix and match just fine. 16 levels X 3 looping 1-minute ambiences = 48 minutes of ambience Cinematic Sound Design/FX: The cinematics will be in-game based (not FMV) so technically they will be handled the same as the in-game sfx (SPU based). I would estimate another 10 unique sfx per level to be used in the cinematics. Cinematic SFX: 10 sfx X 16 levels = 160 sfx Menu/Sub Menu SFX: Would depend on the look and style of the menus. Menu SFX = 10 sfx Sound Design Totals In-Game: Environmental: Cinematics: Menus: TOTAL: 800 sfx 48 minutes/sfx 160 sfx 10 sfx 1000 sfx (approx.) Sound Design = $30,000 124 Chapter 8: Game Design Document DIALOGUE/V.O. Because of the sci-fi nature of the game, effects will play an important role in the creation of the voices. All sorts of robotic, helmet gear, radio, flange/phaser, strange and unique effects will be used in pre- and post-production. Think Star Wars. Cinematic Character voices: Genesis Contact, Player, Aegis, NPC Buyer, First Guard, Genesis Man, Oberon, Black Dragon Master, Genesis Operations Officer, Fire Elder, Fire Elemental, Piwan, Dr. Tan, Agent Cassandra, Protagonist, Babbage Entity, Elder, Tea-Drinking Society Operations Officer, TDS Ops, Hashi, Dr. Kellon, Tran, Automated Receptionist, TDS Shuttle Captain, Charles, TDS Man, Gardener, Zubrin Marine, Zubrin Operations Officer, Lao, Zubrin Man, Zubrin Merc, Civilian, Zubrin Ops, Ambassador. (35 total) Enemy voices: There would also have to be enemy character voices recorded. Screams, yells, hits, jumps, dies, etc. We would need about 15 actors to record 35 characters. Each professional non-sag actor’s price would vary depending on experience, how many characters, versatility, etc. These are not one-liners (like Boxing), this is more serious acting. SAG rate for a 4-hour block-out (3 characters max.) is $612.00. To get non-SAG actors (who are really in SAG) for a buyout usually costs about $750. Some actors will charge $1000 and others will cost only $500. $750 I feel is a good average for a non-SAG buyout. It should take 3 studio days to complete the script. In a script of this nature (characters, acting, size, etc.) it is always smart to put a 10% contingency in the budget for call-backs. Actors: Studio: Casting Agent: Editing,Mastering: Contingency (10%): Total: 15 X $750 = $11,250 3 days X $1000 = $3,000 $1,000 $5,000 $2,000 $22,250 This is my recommended buget. GRAND TOTALS: Music: Sound Design: V.O.: Total: $53,000 $30,000 $22,000 $105,000 Breathe, David… breeeeeathe….. Now count to 10. Okay good! Please realize that this is a huge game and there is a ton of audio here. I have given my $1,000 per minute of music rate (usually $1,200-$1,500) because there is quantity. Same for the sound design; normally for the amount of sounds required it would be much higher. If you were to go to any company in the industry and ask them for this amount of work you’ll get prices that are a little lower and some that are much higher. The prices I cannot come down on. I cannot go lower than $1,000 per minute and I can’t do 1000 sfx for under 30K. If we needed the budget to be lower we could do the following… Music: Please keep in mind that the recommended budget was NOT a wish list. I had to struggle to get the minutes of music to where it currently is. Notice that each tune is only approximately 1:30. 2 to 3 minutes is usually the norm, but I feel that because of the ambient style of music we will be using that if I’m tricky with my loops I can get away with 1:30. We could easily just take the music figure down to about 40 minutes and just deal with it. It does start to take a quality hit as far as repetitiveness goes (which I am already assuming in the 53 minutes), but it’s not the complete end of the world. New total: 40 minutes of music. Chapter 8: Game Design Document 125 Sound Design: The sound design is a tough one because there is no getting around it! The game is big and there are tons of SFX. If worse came to worst and we really had to squeeze it all together we could unhappily shave an extra 5K off the 30K figure and use less looping ambiences and reuse in-game sfx for the cinematics. Once again, quality would go down because of repetitiveness. New total: Approximately 800 sfx. Dialogue/V.O.: This one is a little easier but the consequences are greater! We could easily get a bunch of actors @ $500 but I can guarantee you that the quality WILL NOT be great. Acceptable, but not great. We could also take out the 10% contingency and just live with what we get in the sessions. New V.O. total with those changes = $16,500 New Grand Totals: Music: SFX: V.O.: Total: $40,000 $25,000 $16,500 $81,000 If you are thinking of making this game an A or AAA title, the 100K budget is absolutely necessary. For a B title you can easily get away with the 80K figure. Anything less and you’re headed for the C title blues. Let’s discuss once you’ve had a chance to digest it all and talk it over with some people. Thanks, Tommy The music requirements for Black9 will need to be created. For a firstThis is a sort of catchall category that is person shooter, enumerate the weapon specific to your game’s genre and tech- effects and explosions. For a platformer, write down the magical effects nical implementation. For example, in Starfleet Command a list of the weapon when the character picks up a power-up or gathers another star or crystal. effects, astronomical features, and other system effects like tractor beams Special Effects 126 Chapter 8: Game Design Document WEAPONS AND AMMO WEAPON Cost AMMO Range Damage R-O-F Magazine Size 15 5 5 30 1 5 1 1 1 Magazine Cost $15 $20 $20 $5 $10 $10 $5 $25 $20 Categorization Weapon Type Illuminati Specialty? Threat Level Mission First Available 1 1 1 1 4 4 7 7 7 1 grapple across open spaces, but vulnerable to attack as it becomes the equipped weapon Comments 9mm Pistol Shotgun (sawed off) Shotgun Sub-Machine Gun Sniper Rifle Silenced Pistol Crossbow Crossbow Crossbow GrapplingHook Crossbow $1,000 $800 $700 $5,000 $20,000 $15,000 $5,000 $5,000 $5,000 Bullets Shells Shells Bullets high-caliber rounds Bullets Bolts Poison-Tipped Bolts ExplosiveTipped Bolts 21 10 25 45 300 15 60 60 60 10 15 10 8 25 5 10 3 25 5 3 3 9 1 5 1 1 1 Firearms Firearms Firearms Firearms Firearms Firearms Special Special Special Special pistol rifle rifle pistol rifle pistol rifle rifle rifle rifle no (global) no (global) no (global) no (global) no (global) no (global) Tea-Drinking Society Tea-Drinking Society Tea-Drinking Society Genesis Magnum Pistol Suitcase Gun Grenade Flashbang Mine Tripbomb Motion-Sensor Bomb Satchel Charge MIRV Grenade $1,500 $2,000 $25 $10 $50 $80 $120 $75 $150 high-caliber rounds Bullets N/A N/A N/A N/A N/A N/A N/A 24 12 8 8 n/a n/a n/a n/a 8 15 5 30 5 50 20 40 75 15 ea 5 1 1 1 1 1 1 1 1 5 3 1 1 1 1 1 1 6 $10 $25 $25 $10 $50 $80 $120 $75 $150 Firearms Firearms Explosives Explosives Explosives Explosives Explosives Explosives Explosives pistol pistol thrown explosive thrown explosive dropped explosive mounted explosive mounted explosive dropped explosive thrown explosive mounted explosive thrown explosive no (global) no (global) no (global) no (global) no (global) Zubrin Zubrin no (global) Zubrin 4 8 1 4 4 12 12 5 12 explodes into smaller grenades Detonation Pack Flare Grenade $100 $30 N/A N/A n/a 8 100 3 1 1 1 1 $100 $30 Explosives Explosives Zubrin Genesis 12 4 blindness lasts longer than flashbang Rocket Launcher Rail Gun Flamethrower Grenade Launcher $30,000 Rockets, MIRV Rockets, Guided Missiles high-caliber rounds fuel Grenade Shells, MIRV Grenade Shells, Remote Detonation Grenade Shells (aka Pipe Bombs) none (recharges) Bullets Bullets 200 50 2 5 $180 Heavy Weapons Heavy Weapons Heavy Weapons Heavy Weapons launcher Zubrin 12 $75,000 $6,000 $4,000 200 10 100 60 40 30, 15 ea, 30 3 1 1 10 5 8 $250 $50 $200 armature rifle launcher Genesis no (global) Zubrin 5 5 12 Rad Flux Rifle Assault Rifle Heavy Machine Gun Katana/ Wakizashi pair Blit Sword $100,000 $10,000 $25,000 80 90 200 25 20 20 5 8 10 n/a 30 100 n/a $50 $75 Heavy Weapons Firearms Heavy Weapons Melee Weapons Melee Weapons Melee Weapons Melee Weapons Melee Weapons Melee Weapons rifle rifle armature Genesis no (global) no (global) 5 1 5 $5,000 $9,000 N/A N/A 0 0 30 40 3 4 n/a n/a n/a n/a two-handed melee one-handed melee one-handed melee one-handed melee one-handed melee one-handed melee no (global) Tea-Drinking Society 1 7 curved blade conducts energy from tip to base Stun Gun (Tazer) Blackjack Dagger Blit Dagger $500 $100 $150 $250 N/A N/A N/A N/A 0 0 0 0 5 2 5 6 1 1 1 1 n/a n/a n/a n/a n/a n/a n/a n/a no (global) no (global) no (global) Tea-Drinking Society 1 1 1 7 curved blade conducts energy from tip to base Chapter 8: Game Design Document 127 WEAPONS AND AMMO WEAPON Cost AMMO Range Damage R-O-F Magazine Size Magazine Cost Categorization Weapon Type Illuminati Specialty? Threat Level Mission First Available Comments All Guns are data linked Manufacturers: Krupp, Sakamoto Designs, KIM – Kim International Munitions, Mossberg, Specialty Defense Systems, SkullCracker Note: if Illuminati restrictions are too harsh, could be changed so that buying those weapons when in the employ of that Illuminati is cheaper, and outside the employ the weapons must be secured on the black market, and are thus more expensive. Restrictions can also be tweaked or dropped based on design analysis and QA gameplay feedback. Note: mission appearances are subject to change after design analysis and QA gameplay feedback. The weapons and ammo list for Black9 Stepping Back a Bit Looks like a bunch of work, huh? Good, that is why it is a job being a game designer and not a hobby. If it seems a bit daunting to undertake this effort in writing up your game, I have a suggestion. Practice the skill of game design by writing up the game design of an existing game. Go through this entire rigor on a game that is already successful! It is perfectly reasonable in any other profession—medicine, engineering, automotive repair—to practice the skills involved before moving on to practicing the profession. Even novelists can take creative writing courses and budding scriptwriters can take scriptwriting courses. So I think it is perfectly logical that a game designer should practice writing detailed game design documents by analyzing another game designer’s game. This page intentionally left blank TE Team-Fly® AM FL Y Chapter 9: The Technical Design Document 129 Chapter 9 > > > > > > > > > > > > > > > > The Technical Design Document This chapter introduces the technical design document and the work involved in putting together the technical plans for creating your game. As an introduction, this chapter includes the concepts in a light overview designed to kickstart your technical design process; however, it is Chapter 18 that discusses the technical design stage in detail. Object-Oriented Design Modern electronic games are large software projects that run from hundreds of thousands of lines of code to millions of lines of code. Objectoriented design (OOD) was invented to cope with large software projects. I am not going to fill up this book with pages discussing the pros and cons of objectoriented design versus procedurally designed software; there are countless good books discussing object-oriented design at your favorite bookstore. I am already sold on OOD, and I approach the technical design document using OOD; I am only concerned here with the application of OOD and UML to game construction. There is also a bias towards C++ as the language for implementation of the game code. Where the technical design document lies in the project life cycle 130 Chapter 9: The Technical Design Document There are a few other important languages for creating games such as C and Java. I will not evangelize for C++ here either. If you are using Java, then you are probably creating a game without significant performance requirements for graphics and are interested in cross-platform distribution. If you are using C, then you have probably made the determination that C++ is not yet right for your team or have some other requirement keeping you with C. Assembly language is of course used when hand optimizing critical sections of code and is not relevant from an architectural or design point of view. Purpose of the Technical Design Document The technical design document is the blueprint for the software engineers on your team to use in the creation of the game. The ideal technical design document will specify to your developers not only what needs to be created but also how it will be implemented. I was introduced to strong software architecture for the first time in the game industry when I worked under Jay Lee at Interna (a game company that has since joined the mound of defunct game companies). When I signed up for the job as a developer at Interna, I was looking to learn more about C++ and artificial intelligence. What Jay Lee did was to use strong encapsulation of the implementation details by creating a detailed set of interfaces for the classes of the whole game (a massively multiplayer casino game). Jay labored for two months writing header files. There was not a bit of working code at the end of his two months, just header files. I remember that the members of the team were a bit skeptical about this; we thought while leadership was great and architecture was probably a good thing, would it not be better if our best programmer were writing some code? Well it turned out that it took three junior developers just three months to flesh out the source files as indicated by Jay’s headers to implement the software Jay described. It was the fastest any of us saw software come together. JARGON: A header file or a .H file is a file in C or C++ that describes the interface to the software module defined in a corresponding source file (.C or .CPP file). Jay Lee demonstrated very strong software architecture; ever since that experience I have been learning more about creating software better. The relationship between software architecture and the technical design document is that the technical design document is broader in scope and less detailed than a software architecture plan. The technical design document must synthesize the requirements of the game, develop a software design, serve as a testing plan, and also supply the project manager with critical information such as the required developer roles, dependencies between tasks and developers, and an estimate of how long it will take to perform each of the tasks assigned to the developers. Chapter 9: The Technical Design Document 131 in a game’s development. Often they cannot visualize the game the way the game designers are able to and are forced to green-light a project based on feelings of trust in the developer. All executive management teams would rather replace this trust with seeing some cool eye candy on the screen showing that the game is The conceptual overview of a technical design document happily in development and looks fun. This creates an unholy tension when the developer is pressured to not think The technical design document has about the technical design of the game other customers besides the developers on your team: The game publishers much in the early stages and must are becoming savvier in their technical instead play catch-up all project long. It is widely known in the software engievaluation of game developers as the neering field that you would much scope of the projects grows and the rather identify and fix a defect in your associated risks with the projects software at the design stage than at the increase. Most likely you will need to deliver a technical design document as end of the project. Estimates vary, but the consensus appears to be that it is an early milestone to your publisher. fifty times more expensive to fix a bug The problem with a technical design at the end of the implementation stage document is that while most of the than at the design stage. Thus, I strong publishers are now asking for them, there are few senior game devel- encourage you, by whatever means you can, to take your time on the technical opers with the requisite technical design phase of your project and work expertise to perform an adequate closely with your publisher or execureview of the developer’s technical tive management to make the work of preparations. This lack of technical review means the technical design doc- the technical design stage visible and reviewed to assure that progress is ument will be poorly reviewed and as occurring on the project. Email me if such is not a very visible deliverable. This creates another problem; early in you come up with tips on how to get the project the executive management publishers more excited about the techis almost always eager to see progress nical design document. 132 Chapter 9: The Technical Design Document Strong process, poor process—relative efficiencies The later you identify and fix a bug, the more the cost rises. Why Have a Software Development development process is the method Process? your team uses to take the game specifications and turn them into a game. All development houses have a develEven the solitary game developer opment process even if they do not working on her own private game, iterconsciously go about creating one. A ating each night after working the day Chapter 9: The Technical Design Document 133 job, still has a development process. This lone developer’s process could be as informal as writing up a sketch of the main game interface on a piece of graph paper and then incrementally building the game, a new feature every night, until the game is playable. Some high-profile game development companies also use this method. Steve McConnell’s seminal book Code Complete is one of the most accessible works discussing in detail software development methods and why organizations resist learning new development processes. The problem with learning a process is that it takes time, and most organizations are in short supply of time. They are under great pressure to get something visible and running as quickly as possible to reassure management that the project is well under way (a recurrent theme in this book, I know). A strong software development process will emphasize thinking at the beginning of a project where a weak development process will create an even larger burden of wasted time at the end of the project. In the most extreme cases of poor process, the projects find themselves in such a hole of despair due to poor decisions made at the beginning of the project that the project itself is cancelled rather than throwing everything out and trying again. I am firmly convinced that all of the games in the industry that are taking 30 to 60 months to complete are being performed at development houses with a poor development process, which results in a poor preproduction. It is understandable why game development companies are generally poor at enforcing a strong software development process. First of all, most software companies are poor at the development process by all accounts; second, the industry holds creativity sacred (a good thing, but it can be used as an excuse to avoid professionalism); and third, the games themselves are always becoming larger, faster, and more complex—about at the rate of Moore’s Law. The result is that studio heads or publisher executives who might have had hands-on experience in creating a game five years ago now have a misguided interpretation of the scope of the project they are responsible for. Interpreting Moore’s Law liberally, it would suggest that over five years a game would be eight times larger in complexity and scope than an equivalent title five years before. This last point I think is significant and rarely discussed; managers are often walking around with an impression of the work to be completed as much smaller, like when they were creating games hands-on. They were successful then, or they would most likely not have achieved their leadership position. That means they must have been successful with their software development process and that the penalties back then were correspondingly smaller. I think this is a great source of subtle evil in the game industry. JARGON: Moore’s Law—computing power will double every 18 months. So are you ready to hear about a better software development process? The Unified Software Development Process We at Taldren use a modified, light version of the Unified Software Development Process. I will, however, present an overview of the full Unified 134 Chapter 9: The Technical Design Document Software Development Process and The Unified Process recognizes that a then go back and explain what we do. real-world project cannot crisply comThe core workflows of the Unified plete one workflow and then move to another workflow. To address this, the Process are requirements, analysis, Unified Process is an iterative and design, implementation, and test. Looking over this list of five activities, I incremental workflow method, where each stage of the project is driven would imagine most people in game development would be surprised to see through inception, elaboration, constructhe three preproduction activities: tion, and transition. requirements, analysis, and design. If I Phases of a Workflow in the Unified were to interview game development Process houses to ask them what core 1. Inception workflows (after explaining what I 2. Elaboration meant by the term) they are using in their development, they would probably 3. Construction say design, implement, and test. This is 4. Transition one of the key features of the Unified Process; it formally recognizes that gathering your requirements is a different activity than analyzing the requirements, which is in turn a wholly different activity than design- The work flow of the Unified Software Development Process ing your software to meet your game’s In the real world you will find yourself requirements. If you think back towards late in the project, perhaps near alpha, an earlier chapter on gathering your when you realize that your game invenkey business parameters before creattory system is broken and not fun (it ing your game design document, you turns out tracking the adventuring gear will notice that I added a bit of material to the nearest gram was not a great from the game development domain to idea), so now you need to go back and the requirements capture stage. design a new inventory system. The Core Workflows of the Unified Process 1. 2. 3. 4. 5. Requirements Analysis Design Implementation Test Unified Process would have you stop and think about your new inventory system, review your requirements, analyze what impact the new inventory system requirements will impose on the existing game, design the new Chapter 9: The Technical Design Document 135 The various models of the Unified Software Development Process inventory system, implement it, and test the inventory system. Perhaps at this point you may be getting bored and rolling your eyes and thinking to yourself, “This is just a bunch of fancy multisyllabic names; of course I think about my stuff before I code it.” While it is true that these terms are just a bunch of jargon, if you actually consciously name what activity you are performing, you will have a much greater awareness of what you are doing. This awareness will translate directly into being more purposeful about collecting your requirements when the sign over your head says you are in requirements capture; you will be a far more effective analyzer of the requirements when you are not obligated to think about how you are going to code the rasterizer. Your designs will be much stronger when you have all of the requirements and their impact laid out in front of you. When Should the Technical Design Document Be Written? The technical design document should be developed in preproduction along with the game design document but perhaps staggered back a bit to allow the game design document time to form up. The technical design document needs to be developed with a thorough set of plans and time estimates before the schedule and the project plan (discussed in the next chapter) can be completed. During production it sometimes becomes necessary to change the direction of some features in response to technical research, focus group testing, market research, or an awareness of a lack of thorough design in the preproduction stage. In response to any change in the game, a fast response mini-technical design stage should be initiated before any new development of these changes is undertaken. In other words, don’t allow your deeply thought-out technical designs to be 136 Chapter 9: The Technical Design Document held up like stone tablets that must be followed. By all means, change your design during implementation if you identify a better design. What Goes into the Technical Design Document? Now that I have established that a technical design and architecture are good things to have, it is time to define what goes into the technical design document. The technical design document acts as a plan of attack on the requirements of the game: a plan for whom, when, and how these requirements will be accomplished. This technical design document is a miniature project itself going through several stages: requirements capture, requirements analysis, high-level architecture, mid-level software design, deployment design, a testing plan, and a transition plan. Each of these stages will be chock full of documents, diagrams, and time estimates to complete the tasks described within. Requirements Capture Requirements capture is the process of identifying all the requirements the game as a piece of software must satisfy to meet the goals and expectations for the game. Requirements can take a myriad of forms from a frame rate requirement of 60 frames per second, to fitting on a Capturing use cases single CD, to not taking more than 80 proThe requirements capture stage is the grammer-months to complete, to most critical to a successful project and having very few defects, to having 3D sound or 10,000 polygon characters, to in many ways is the most difficult. It is being part of the engine development. The goal is to write down every single expectation the team, the executive manager, the designers, and the fans have for the game. Note that this stage is named simply requirements capture; there should be no efforts to cull, prioritize, or otherwise analyze the requirements and make any decisions. The goal is to just cast the net as wide and as far as possible and be very thorough in collecting all of the fine details. Any premature efforts to analyze the incoming requirements will bog down the process and create decisions that are made on less than the full set of information available to make these decisions. Chapter 9: The Technical Design Document 137 difficult to decide when you have identified all your requirements, and it is also sometimes difficult to describe them clearly, such as when you are trying to push your graphics to the “next level,” whatever that might be. Let us tackle it in order of easiest to most difficult. The easiest requirements to capture are the requirements described in the game design document! This document should have a design for the main game interface, the shell screens, the game mechanics, the art design, and the content such as missions, levels, and puzzles. The Unified Modeling Language has the use case diagram, which is most helpful in the requirements capture stage. The idea behind the use case diagram is to note the actors (users and other discrete systems such as a CD authentication server) and the interactions these actors have with the software system. The use cases of the officer menu in Starfleet Command 3 138 Chapter 9: The Technical Design Document The mocked-up officer screen early in production The nearly final officer screen TE Team-Fly® AM FL Y Chapter 9: The Technical Design Document 139 The above use case diagram is from Starfleet Command: The Next Generation. The function of this menu is to act as a vending machine, “selling” new officers for the players to use on their starship and allowing the players to “sell” back the officers they already have. The purpose of this diagram was to collect every single action the player would have with this menu and arrange it graphically to aid in the technical analysis of what needs to be done. Accompanying this diagram is a regular document detailing these individual interactions or use cases. Officer Menu Use Cases Displays or Player Views These are just views; there are no player interactions in these use cases. View Ship Name This is a simple text display of the player’s ship’s name. View Current Prestige This is a simple text displayer of the player’s current display. Display these prestige points in normal text output color if they have enough prestige to buy the least expensive officer in the base; if not display this prestige as red text. View Starbase Name This is a simple text display of the name of the starbase or location that the player is performing officer selection. In the case of multiplayer or skirmish games, display the name of the mission type. View Current Officer Assignments This is a complex display combining the following elements: • • • Officer Name Station Name and/or Station Icon Officer Trade-In Value This display displays six such officers; there is no scroll bar. At all times there is to be an officer displayed here; even when the player transfers out an officer, a flunky ensign with basic skills throughout will be displayed. We need a long list of potential officer names that is race specific and easy to add to. View Officer Profile This is a complex display combining the following elements A and B: A. Officer Attributes • Officer Name • Officer Intelligence • Officer Toughness • Officer Health • Officer Cost to Buy / Officer Trade-In Value B. Officer Skills Each of the skills is broken down into three sub-skills and a display of skill rank. The skill rank should have a header of skill rank rather than the vague info as depicted in the current interface diagram. The skill rank should be a word description: • • Basic [Green Text]: A basic understanding of the skill category. The officer can perform the skills in this category, but with a negative impact on ship performance. Trained [Blue Text]: Trained. The officer’s performance has no effect on gameplay and is altogether neutral. 140 Chapter 9: The Technical Design Document • • • • Skilled [White Text]: Skilled. The officer will impart some slight improvements in game effects to the performance of ship operations in this skill category. Veteran [Yellow Text]: Veteran. The officer will bestow modest improvements to ship performance in this skill category. Expert [Orange Text]: The officer has attained a skill that few others can compare; the gameplay effects are fairly strong as an officer effect. Legendary [Red Text]: The officer has attained a level of skill that is unearthly. They are miracle workers. Helm Skills • Thruster Control: Improve acceleration • Piloting: Turn radius • Emergency Procedures: High energy turns (HET) breakdown adjustment Engineering • Thruster Efficiency: Improves maximum speed • Warp Technology: Reduces vulnerability time before and after warp • Inertial Dampener Technology: Reduces the effects (recovery time and regeneration) of breakdown OPS • Scanner Technology: Improves the range and effectiveness of the scanner systems • Cloak Counter Measures: Decreases enemy cloaking effectiveness • Find Weakness: Finds weak spots in the enemy’s defenses, which in turn increases weapon effectiveness against targeted ships Security • Close Quarters Combat: Increases combat effectiveness of Marines • Defensive Planning: Increases ships’ natural resistance to raids and boarding • Fitness Program: Decreases likelihood of officers getting injured, including damage from any assassins Medical • Psychology: Sustains crew morale across missions • First Aid: Increases the likelihood that an officer who is stunned recovers quickly • Surgery and Recovery: Increases the likelihood severely injured officers survive Tactical • Targeting: Increases weapon efficacy • Troubleshooting: Reduces the effects of weapon degradation due to damage • Counter Measures Training: Reduces the effectiveness of both natural and artificial ECM View Available Officers This is a complex display combining the following elements: • Officer Name • Officer Cost to Buy • Best Officer Sub-Skill • The Skill Rank in this Sub-Skill If there are no officers available at this starbase, display this text: • “No officers available” • • • This display is a scrolling display with no limit to the number of entries. The cost of the officer should be displayed in red if the player does not have enough prestige to buy the officer. The skill rank of the best sub-skill for the officer should be colored by the schedule of colors from the previous section. Chapter 9: The Technical Design Document 141 Player Activities Cancel All transfers in and out and auto-assignments of the player’s officers are thrown out and the officers the player had in place when entering the menu are restored as well as the prestige the player had at the start. The player is then returned to the source menu or activity from where they came from. An “Are you sure?” modal dialog might be a good addition to this choice. Accept All transfers of officers in and out of the ship and auto-assignment of officer stations are committed as well as the prestige changes. The shadow copy of the officer assignments from the beginning is thrown out. The player is then returned to the source menu or activity from where they came from. An “Are you sure?” modal dialog might be a good addition to this choice. Transfer Out The officer that is currently selected on the side of the player’s ship—the crew manifest—is transferred off of the player’s ship and is placed in the starbase (and is viewable there). When the player transfers an officer out they only receive a K constant on the trade-in value for the officer. I would like to initially set this value to 1.0 so that the player has no inhibition on transferring their officers from station to station. However, I would like to be able to change this value later, for balance or difficulty settings. It should always be successful to transfer an officer out. The transfer out button is always available. If the player selects one of those basic ensigns with no skill, it just disappears into the ether and cannot be effectively transferred to a new station. This is to prevent the player from transferring out their infinite supply of ensigns and filling up the starbase. Transfer In The transfer in button will take the officer currently selected on the starbase side and swap places with the officer currently selected on the player’s ship side (effectively performing a transfer out of this officer at the same time). If the player does not have enough prestige to transfer in the selected officer from the starbase, then the color of the cost of that officer is red and the transfer in button is not enabled. Auto Assign By a simple algorithm the officers on the player’s ship will shuffle about to have the officer with the best skill for each station. The algorithm should be something like this: Take an officer and average the officer’s Medical sub-skills to compute an average Medical skill rank; repeat this with all major skills and all six officers. Now sort the officers in order of who has the highest major-skill value from largest to smallest. Whomever is at the top, assign them to the station that corresponds to the skill that has the highest major-skill rank. Keep going down the list until all six stations are filled. The use cases of the officer screen A fundamental tenet of the Unified Modeling Language (UML) is that you should never create documents and diagrams just for documentation’s sake. You should use your own judgment on how much rigor you should apply to the problem. That is because beyond the use case diagram, UML offers eight more diagrams such as the test case, the activity diagram, the sequence diagram, the class diagram, the package diagram, and the deployment diagram. This could be a bewildering array of diagrams if you went about every menu with nine different diagrams and 50 pages of supplemental text. You would quite clearly never make a game, but you might make a bureaucrat proud. 142 Chapter 9: The Technical Design Document With that cautionary statement about not going overboard, I think it is well worth your time to collect all the use cases that directly involve the player. Unlike most business applications, we game makers have the player perform many interactions, and some are quite complex. Take the time to create a use case diagram for each shell screen. Most of these you will not need to document much, just some notes here and there about how many characters that text entry should take, how many digits that display should produce, and so on. It is absolutely required that you create a menu flow (my term) diagram to chart the flow between your shell screens. The main display of your game, whether it is an isometric role-playing game, a starfighter game, or a racing game, should be where you put in most of your use case analysis time. Take the time to mock up the display in Adobe Photoshop or some other layout tool. Then carefully hunt and peck for every interaction and requirement you have for the main display. I would recommend using a whiteboard or a piece of graph paper to collect this first pass of interactions and use cases. Next, rearrange your use cases to factor out common functionality or behavior from your various interactions and create your use case diagram in a tool such as Visio. As a last step, adorn The menu flow diagram for Black9 Chapter 9: The Technical Design Document 143 describe the existing engine. Last year at Taldren, when I hired Ken Yeast to take over maintenance programming for my area of SFC: Empires at War, he had a little trouble wrapping his mind around the sequence of events and interactions involved in the matching of humans and AIs in the online gameplay for SFC: EAW. Ken not only came up to speed with my code in an efficient manner, but was actually fixing subtle and complex bugs with the ability to “see” what is expected of the system. No matter how hard you look, you An example of adornment will never uncover all the use cases and system requirements for your game To be productive with interactions, do project during the technical design pornot attempt to analyze the use cases tion of preproduction. Don’t worry into anything that resembles impleabout it; anytime you discover a new mentation. At this point you do not care use case, just figure out where it is fachow the interactions will be handled; tored into existing behaviors, if any, and rather you just want to know what the update the use case diagram and supinteractions are. plemental text. Reverse Engineering Nonobvious Requirements your use cases that have certain requirements, like a frame rate of 60 seconds, that are not direct interactions. This can be articulated as a note on the view main display use case. Now all this is just fine when you are working from a clean slate, but in this world of licenses and franchises you will often find yourself working on a sequel or port of a previously released game. Use case diagrams are a valuable tool for performing reverse engineering, that is, taking a system that is already built and working backward to understand how it works. Understanding how the existing system works is a key step to successfully taking over someone else’s code base. Here all of the use cases are already functional in an existing game. Your job is to play the game and take note of every interaction the player is having with the game and every requirement expressed in the previous game and produce use case diagrams and use case documents to Here are some other nonobvious requirements that your game may have: Design requirements—you want the game to support user extensibility, such as a map editor or a scripting language, or use an existing code base. Interface requirements—similar to a design requirement but closer to the code, such as using OpenGL over DirectX for portability. Implementation requirements— these are unusual coding standards such as the commerce level of transactions and database storage when implementing your own billing system for an online massively multiplayer game. A simple example is the platform for your game—PS2, PC, GBA, etc. 144 Chapter 9: The Technical Design Document the collection of diagrams, text, and designs that lie between the requirements capture stage and the deeper design stage. It will be in the design stage that you make your final plans for the construction of the software. In Requirements Analysis short, the analysis model is perhaps a The purpose of the requirements analy- fancy name for your first pass at the sis stage of the technical design rest of your technical design. You can document is to take the use case model create a package diagram recast in the of the game, which describes the game analysis model, a sequence diagram, in terms of player interaction, and cre- or a collaboration diagram. What you ate an analysis model of the game in the are seeking to do is iteratively move highest level of technical design for the towards the deeper, more specific condeveloper. The following table enumer- structs. The goal is to avoid creating ates the purpose of the analysis model. bugs and defects in the game’s design and architecture that could be fixed Use Case Model Analysis Model now just by rearranging some symbols Described using the Described using the in Visio rather than rewriting a tree of language of the player language of the game classes near the shipping of your game developer due to a subtle bug. You must use your External view of the Internal view of the judgment here to decide how far to game game push the analysis model. Getting the External structure by Internal structure by client-server interactions of a masuse cases use of stereotypical sively multiplayer game is a place I classes and packages would feel comfortable taking my time. Used primarily to build Used by the game Looking over the previous table, it a contract between the developers to is clear that no matter what software development team and understand how the the publisher (executive game should be development process or lack of one is management, i.e., designed and employed, you will always end up customer) to articulate implemented analyzing your requirements and implewhat requirements the menting the requirements. What is to game must fulfill be accomplished in the requirements Captures the Outlines how to create analysis stage is to pause and take functionality of the the game including a stock of the use case model and “parse” game including high-level architecture; nonobvious this is the first pass at it into developer language by taking the requirements formal design use cases that have been grouped Defines use cases that Defines use case together by factoring common behavior are further analyzed realizations, each one and come up with proto-classes and during the rest of the the result of the basic sequences of events. The idea is design through to the analysis of a use case to start jelling the technical design test cases without committing to final class diaThe analysis model is not the name of a grams; this will prevent you from diagram, rather it is the name given to following what may be the wrong path Performance requirements—examples of these requirements are the all-important high frame rate or a tolerance to a specified level Internet latency. Chapter 9: The Technical Design Document 145 of implementation. In other words, if you start producing final class diagrams in response to the first use case you see, then you will produce a system that best answers that first use case. In any area of the game where you have a complexity of use cases, all of them vying for your attention, you should probably take the time to stop and produce an analysis model of the aggregate use cases. As always, use your judgment; there will be many times parts of your game will not require the rigor of an interim analysis model to be developed before going ahead and creating your final technical design. For example, the menu presenting two buttons to the players requesting them to choose between single player and multiplayer game mode will not require deep thought, and you should just go ahead and take the use case diagrams as the analysis model—with a mockup of the screen and its place in the menu flow, I would call it a final design! Class Diagram The class diagram describes the static relationships and roles of the classes that comprise your game’s software. The class diagram can be exhaustive and detail every class and relationship and be printed out on several hundred sheets of paper and pasted to a wall (we have a couple of walls at Taldren serving this purpose for fun), or your class diagram could be focused on a narrow portion of the game such as the classes driving the AI of the starships in your game. The class diagram is the workhorse of technical design. Most programmers along the road of object- oriented design will discover the class diagram on their own. Either they were faced with a tangled set of code in a maintenance job and started scratching sense out on a graph pad, or perhaps they are facing a complex new system they have been tasked to create, and they want to nail it so they reach for the whiteboard to consider a few different class hierarchies. As the following diagram shows, the class diagram is a simple collection of boxes, each representing a class, and lines between the boxes showing how the classes are related to each other. There are many bits of detail and formal notation we could add to the class diagram such as descriptors declaring a method to be public, private, or protected, and whether a class is a template class or whether we are referring to an instance of a class—an object. These additional bits of notation are a part of the UML I will introduce later, but for the moment let us just consider the essence of the class diagram: classes and relationships. A basic class diagram 146 Chapter 9: The Technical Design Document Relationships The class diagram models the static relationships between the classes. It does not model any dynamic behavior of the classes such as when they are instantiated or destroyed, and it does not describe the message flow between the classes. It is the relationships between the classes that make a class diagram a picture of value rather than just a collection of boxes on a piece of paper. These relationship lines describe the dependencies between the classes, and these dependencies define the architecture of your game. There are several vocabulary words that are employed in formal OOD to describe the relations between classes, however they are all variations of three possible relationships. The “is a” relationship is used when one class is derived from another class. An example of this is: a textbook is a child class that “is a” book. The “has a” relationship denotes the relationship between a class that uses another class in its composition. The textbook class could have a “has a” relationship with the page class. Very neat and tidy, eh? Well, I have a loose end. There is one more relationship that occurs between classes; it is the compile time dependency in which one class uses another class in the implementation of a method (also known as a function). Any module that manipulates strings is quite likely to include the header file string.h from the Standard Library. Each type used as a parameter in a function creates a dependency between that class and the invoked type. Drawing every single dependency relationship between a class and all of the other types that are employed in methods of our class under study would only create a very hairy diagram sporting way too many lines to be useful. That is why the dependency relationship is a kind of third cousin to the more important “is a” and “has a” relationships. Drawing “is a” and “has a” Relationships and Ordinalities The “is a” relationship is denoted by a line between two classes with an arrow on one side pointing to the parent class. The “has a” relationship is just a line. The “has a” relationship line is often adorned with the cardinality of the relationship on either or both sides. An example: The “has a” relationship between the textbook and the page class would have the Arabic numeral “1” on the side of the textbook and an asterisk “*” on the side of the page class. This shows an indeterminate number of pages contained in the textbook. It is also quite possible to be more specific. The relationship between the die class and the face class could be adorned with a “1” on the side of the die class and a “6” on the side of a face class unless you are playing third edition Dungeons and Dragons as I like to do from time to time; in that case the relationship between die and face would need that asterisk back again to account for your pile of 20-sided, 12-sided, 10-sided, 8-sided, and 4-sided dice. Chapter 9: The Technical Design Document 147 Focusing on the difference between “is a” and “has a” relationships Adding Annotation Quite often you will want to add important information and details to a class diagram that is not a class or a relationship but a note. To add a note to your diagram, simply draw a rectangle and dog-ear a corner, then draw a line to the class, object, or relationship that you want to clarify. Adding performance requirements such as “must render a steady 30 frames per second to the 3D view class” is a good example of a relevant notation. Other UML Diagram Types The class diagram is one of the diagrams used to perform structural modeling. Two other UML diagrams for structural modeling are the object diagram and the package diagram. The object diagram is a variation of the class diagram where the instanced objects and the relationships between these instanced objects are the focus of the diagram. The class that the object is an instance of is semantically designated by naming the object box like this: Goblin: Monster. Important attributes and values of the object are listed below a dividing line in the box as seen in the accompanying diagram. An example of an object diagram The Unified Modeling Language provides a number of diagrams that support different areas of technical design and software architecture. In a later section I will cover in greater detail the diagrams I find useful. Here I will present the briefest of introductions to the rest of the UML diagram family. Package diagrams are used to organize your class diagrams. Once you have about a dozen or so classes on a sheet of paper, they will start to blur together and lose their meaning. A package diagram looks a lot like a collection of file folders where the interesting bits of class are listed inside the file. 148 Chapter 9: The Technical Design Document Dynamic Modeling Structural modeling is the modeling of how the software will be constructed from a static point of view—in short, the activity you would imagine when setting out to architect your game. However, your game also has dynamic functionality, and UML has diagrams to handle this activity. Remember flow charts? UML has polished up the flow chart and now calls it the activity diagram. The activity diagram models the logic flow from start states to end states. Sometimes a simple state diagram cannot model the complex message flow between various objects performing interesting tasks in your game. For example, in a client-server game there is often a complex flow of data going back and forth from the clients initiating requests and providing user input and the server taking all of this information in, resolving the game actions, and sending out packets to cause the clients to correctly update their TE AM FL Y An example of an activity diagram An example of a package diagram displays. A very useful diagram to model this detailed, complex behavior is the UML sequence diagram. A few more esoteric elements of dynamic modeling remain behind the curtains, and I will leave them there for the time being; see me again in Part III. Team-Fly® Chapter 9: The Technical Design Document 149 Architectural Diagrams An example of a sequence diagram Modern games are becoming large pieces of software that need to be designed and orchestrated on a macro scale. The UML provides component diagrams to illustrate the relationships between modules, libraries, dynamically linked libraries, databases, and other significant chunks of your whole game’s software composition. UML also provides a deployment diagram that appears to be useful only for massively multiplayer client-server games. The deployment diagram describes where all the pieces of the software are going to reside at run time. An example of a deployment diagram 150 Chapter 9: The Technical Design Document For most games, especially console games, the deployment of the game software is well understood and a deployment diagram would only be another diagram in your technical design document suitable only for impressing Dilbert’s boss. must be touched. If only a couple of files include this header file, no worries, but if dozens and dozens of files include this header file, look out—you might as well just do a rebuild all. The trick to good large-scale project making is to consistently practice good OO and keep your code moduLarge-Scale Planning and the Evil larized. Very crudely speaking, do not of a Long Build Time get in the habit of copying the include There are a few tricky parts of building directives from one file to another like large software projects that all of this a huge fishing net, hoping to catch the solid planning aims to keep in check. right file. Take the time to verify that The largest bugaboo of large projects is each and every include directive needs large build times. With computers to be at the top of the file you are already amazingly fast and only getting working on. This has been a constant faster every month, it is easy to not struggle with our Starfleet Command care about build times. When your pro- series. When I took over the project in ject builds and runs in five to fifteen 1998 it was my largest project to date seconds after making a change to your and I had a lot of challenges. (I will skip code, you never break your concentra- boring whining comments.) Too far tion. When the build times grow to down the list of priorities was writing about a minute or two in duration, the code with a fast build time. At the time build time might be just long enough we were under heavy pressure to make for you to reflect on what you are doing a date, and all of us thought this game and perhaps be able to perform useful would be it and we would be on to other thinking. Once build times grow to five projects. We had no idea our game minutes or more, you have a serious would be such a success as to merit productivity leak. When build times working with the same code four years reach twenty minutes or more, people later. Our project builds slowly due to will naturally take a walk down the hall its size, but it is a crime that relatively to chat with neighbors, hit the restminor architectural changes cause sigroom, gulp some water, or get invited nificant build times (30 minutes or out for lunch, and two hours may elapse more!). We would love to rewrite the before they settle down again at their entire Starfleet Command code base workstation. from the ground up—that would be the A full rebuild of any large project way to go! However, with tight budgets will take a long time, but a small change we must use as much of the animal as to the implementation of a single func- possible with each release. In this realtion in a file will be a snap for the world example we have chosen to go compiler to change and the linker to the route of incremental refactoring. come up with a new executable for you. Refactoring However, the gray area is where you realize you must change the interface Refactoring is the art and science of to one of your classes and a header file making the code better without adding Chapter 9: The Technical Design Document 151 new features. A smart maintenance programmer will take time to not only understand the code but also to clean up OO foulings and other architectural errors in the code. Refactoring can be applied to cleaning up any aspect of how your code is created. For the latest version of Starfleet Command we have separated the 3D rendering engine into a separate DLL, and we have vastly decreased the labor involved in sending messages back and forth between the client and server. The multiplayer code base both at the application level and the UI level were refactored. And the disappointing UI engine that we inherited from 1998—Quill—we have wrapped a safe and sane coding condom around that performs as advertised while leaving the underlying Quill alone. Refactoring is a pragmatic practice, and I am a practical person. So we are rewriting and polishing up significant chunks of the code as we go, creating better software as we maintain a regular release schedule. Please see the excellent book on refactoring, Refactoring: Improving the Design of Existing Code by Martin Fowler, Kent Beck, John Brant, William Opdyke, and Don Roberts for a full discussion on techniques of refactoring. discussing your coding practices and software design approaches, including a section on build times, could only earn you a nod of approval from the folks who are to review your technical design document as well as acting as the most clear piece of communication to your team about how you intend for build times to be managed. Besides just practicing good OO there is another technique your programmers can employ tactically to sections of the game to dramatically insulate portions of the code from each other. It goes by different names such as Interface-Impl and Insulation. The basic idea is to create an interface class that contains an implementation class. The role of the implementation class is the traditional role of getting the job done, and the role of the interface class is to be the only public access to the rest of the project. This permits the developer of the implementation class to change the attributes and members of the implementation class all day long without needing any other modules to be recompiled! A classic example of the use of insulation is a class that is a stack. The stack could be written using an array or a linked list (or quite a few other data structures) to push and pop data onto the stack. You write this class as clean Insulation as you want, but you will always give away your implementation details in I fear I may be straying a little off the path of the technical design document. the header file. Sure, that information is However, I defend myself by wanting to privately declared, but it is still publicly viewable and, more germane to this convey to you not only passion for point, any changes to the stack classes reducing build times, but also some implementation, say from an array to an practical advice on achieving faster STL list, will cause a rebuild of all modbuild times. I also argue that a section ules that ever used your stack class. in your technical design document 152 Chapter 9: The Technical Design Document // stack.h - implented as an array #if ! defined ( stack.h ) #define stack.h class cStack { private: int* pStack; int size; int length; public: cStack(); cStack( const cStack &stack ); ~cStack(); Stack& operator= (const Stack &stack ); void mPush( int value ); int mPop(); int mTop() const; bool mIsEmpty(); } #endif A stack written as an array // stack.h - implented as a linked list #if ! defined ( stack.h ) #define stack.h class cStackLink; class cStack { private: cStackLink* pStack; public: cStack(); cStack( const cStack &stack ); ~cStack(); Stack& operator= (const Stack &stack ); void mPush( int value ); int mPop(); int mTop() const; bool mIsEmpty(); } #endif A stack written as a linked list Chapter 9: The Technical Design Document 153 // stack.h - fully insulated we do not need to know the implementation #if ! defined ( stack.h ) #define stack.h class cStackIter; class cStackImpl; class cStack { private: cStackImpl*pStackImpl; friend cStackIter; public: cStack(); cStack( const cStack &stack ); ~cStack(); Stack& operator= (const cStack &stack ); void mPush( int value ); int mPop(); int mTop() const; bool mIsEmpty(); }; bool operator== ( const cStack& left, const cStack& right ); bool operator!= ( const cStack& left, const cStack& right ); class cStackIterImpl; class cStackIter { private: cStackIterImpl* pStackIterImpl; cStackIter( const cStackIter& ); cStackIter& operator= ( const cStackIter& ); public: cStackIter( const cStackIter& stack ); ~cStackIter(); void operator++(); operator const void* () const; int operator()() const; }; #endif A stack fully insulated from implementation details In practice there are many variations you can take to elide your implementation details, with the wholesale privatization of the implementation class being the most aggressive and achieving the highest degree of insulation. I have worked on a project that used this method of insulation aggressively throughout the project, and after discussing it in depth with my teammates, in the end we disagreed with the widespread use of insulation. In particular it makes inheriting a class a pain, and while it does save a lot of mind space by hiding the implementation details from the rest of the team, it also places 154 Chapter 9: The Technical Design Document an extra duty upon the developers who have to write the interface and implementation classes. In the end, we decided it is most useful in larger classes like game manager classes, which are likely to undergo a lot of revision in development while at the same time are unlikely to ever have anything derived from them. Please read the detailed and wellwritten book on a relatively unexciting topic, Large-Scale C++ Software Design by John Lakos. Forward and Backward Code Generation with a Modeling Tool So why do I advocate UML particular ’s set of boxes and lines for describing software? Well, any set of lines and boxes will do, as long as you think through the stuff you need to think through and communicate it well to your teammates and project stakeholders. That being said, UML is making rapid progress in being accepted as the industry standard for describing and documenting software. By becoming an industry standard we are now seeing several products on the market that will perform both forward code generation from your diagrams and reverse engineering on existing code. I should let that settle with you for a moment. Think about it; your programmers can link a bunch of boxes together in a class diagram describing the relationships between the classes, attributes, members, parameters, public, private, protected—quite a few details—hit a button, and bam—the files are created and the skeleton code is written! All that is left for the programmers to do is program. That makes UML cool. The reverse engineering part can come in handy when you need to digest a whole mess of code. It really is quite fun and educational to generate large class diagrams and spend an afternoon pasting them to a wall and reading over them to get a feel for the lay of the land. There are several tools to choose from for the creation of UML diagrams, including Rational’s Rose and Together from Together Soft. We have even been teased by Microsoft that Visual Studio 7 will come with a new version of Rose bundled into the development environment. So yes, you can use your own boxes and lines, but why not use the boxes and lines that have software out there that can help you? Testing Plan Towards the end of your technical design document you must have a section on your testing plan. How will you test your game? Toss it to the publisher and fix what they ask? Beta testing, unit testing, black box testing, or white box testing—which will you employ? Unit Testing and White Box Testing Unit testing is the most straightforward of testing procedures. As you finish a piece of your software, write a testing suite to exercise your new piece across all ranges of valid and invalid input and see what breaks. This is the sort of activity developers of the piece of code should implement as a matter of course in the development of their work. Also note that unit testing will not work with poorly architected code as you will have few truly modular parts of your game that can be tested independently from the rest of the game. Chapter 9: The Technical Design Document 155 Beta testing is great; it is putting the game in the hands of people who will buy your game. Fix all of the bugs they identify and you know for sure you are spending your time on bugs that need to be fixed. The problem with beta testing is that it is an exaggerated form of black box testing, where you have fans just playing the game and reporting what they feel like reporting. Beta testers also consume great amounts of the development team’s attention, as they are real people who will express their feelings and need continuous feedback Black Box Testing and direction to keep them happy and This is the type of testing most publish- productive. However, every game (and ers will perform on your game. They product for that matter) should undergo may have organized checklists to folbeta testing, as it is the only way to low, but in the end it will be a bunch of determine if you really are making young folks early in their careers play- something people will enjoy. ing your game in a relatively unstrucFrom Use Cases to Test Cases tured manner, looking for things that are broken. The advantage black box How do you organize your black box testing has over white box testing is and beta testing? Again, UML offers an that since the testing is performed from aid, the test case diagram. The great the user’s perspective with no knowlthing about this diagram is that it is just edge of the implementation details, the use case diagrams from the start of black box testing will often find bugs our project being dusted off and getting that a white box testing plan was not a shiny new label. Remember all of the even looking for. The flip side is that use cases you worked up to describe all since the testing is not based on any the interactions between the player and knowledge of the implementation of the the game? Those interactions are pregame, the testing can become rather cisely what you want to test during unfocused and can consume quite a lot your black box and beta testing efforts. of man-hours in the pursuit of bugs. Just collect all of your use cases and convert them into a checklist of a testing plan for the black box testing team and the beta testers to test. The best kind of unit and white box testing is automated. For example, some developers of 3D games have a test where a computer constantly generates random locations and directions for the camera to look at to see if any positions and/or views cause a crash. In the development of Excel, Microsoft employs three or more redundant, independent algorithms for the calculation of the worksheets and compares the values across them all to identify errors in the algorithm that is being optimized for shipping with Excel. Beta Testing This page intentionally left blank Chapter 10: The Project Plan 157 Chapter 10 > > > > > > > > > > > > > > > The Project Plan What Is the Project Plan? The project plan is the culmination of the planning articulated in the game design, technical design, and other design documents such as an art style guide. The heart of the project plan is a schedule that describes what will be accomplished, how long the tasks will take, and who will perform these tasks. The project plan contains other information such as milestone dates, task dependencies, and a risk management plan. The information in the project plan is published to both the executive management for progress reports and to team members in the form of tasking. It is also used by the project manager to level tasks between resources, identify critical paths, and develop contingency plans. A good project plan will act as a major tool to avoid surprises. All this seems like good stuff, so let us get on with making a project plan. Components of a project plan: estimates, resources, tools, tracking, dependencies, risks, and alternate plans How Do We Create the Project Plan? To create the project plan we will need a list of tasks to be completed, who is available to perform those tasks, when the critical project dates are such as milestones, and what the relationships are between the tasks. The list of tasks, the estimates of how long it will take to perform these tasks, and their dependencies will come directly out of the 158 Chapter 10: The Project Plan The project plan pipeline TE All of this project information will need to be compiled into a usable format for project analysis and report generation. With tools such as Microsoft Project or Primavera’s SureTrak products, a myriad of reports and graphs can be generated to review the workload across team members, understand what the critical path is, measure project progress, and a whole host of other views of your project status. Many people are intimidated by project planning, or they have seen project planning only partially implemented that failed to work. From my roundtables on game production at the Game Gantt and PERT Charts for Organizing Project Tasks There are many reports, graphs, and charts used in project planning and tracking. The two most commonly used charts are the PERT and Gantt charts. The acronym PERT stands for Program Evaluation Review Technique, a methodology developed by the U.S. Navy in the 1950s to manage the Polaris submarine missile program. The PERT chart places each task in a rectangular box with a line drawn to the predecessor task and a line to the next task; thus the whole diagram looks like some sort of tree. The PERT chart’s key feature AM FL Y Team-Fly® game design document and technical design documents. Critical project dates such as milestone and release dates should be iteratively arrived at with the executive management team as the project plan is compiled. Many projects are schedule driven; however, the most common for the game industry is the holiday shopping season from Thanksgiving to Christmas every year. Often projects will be planned by walking backwards in time from November to discover the critical dates like beta, alpha feature lock, first playable. With these projects it will be the project plan that adapts to the critical dates. This is discussed later in this chapter. Developers Conference I discovered there was a fairly wide range of project management rigor applied to game development. Some shops considered themselves too small to plan their work; they just worked on whatever was the most pressing task at the time. Many developers just used simple spreadsheets in Excel to plan their projects; some folks used Microsoft Project to plan their tasks and then followed up in Excel to perform their task tracking; the more determined developers used Project for both planning and tracking; and one large French developer that was part of a construction firm used Project to plan and Microsoft Team Manager for task tracking. Chapter 10: The Project Plan 159 is the visual ease in identifying the relationship between tasks and the critical path of the project as a whole. The drawback of a PERT chart is that its utility is limited to just the higher-level view of a project. When individual tasks of any nontrivial project are displayed, the resulting chart is crisscrossed with lines and is too unwieldy for the viewer to absorb. excels in data entry, as there is no end to fussing about where to put the boxes as in a PERT chart. The project manager usually just needs to enter the task name, estimated time to complete, and a resource to complete the job. A tool like Microsoft Project will automate the graph side of the chart. The Gantt chart will also accept task dependency information like the PERT A PERT chart from Microsoft Project The Gantt chart turns out to be the most generally useful of the project planning and tasking charts. It features a spreadsheet-like data entry on the left-hand side of the chart with any number of columns, the minimum being task name, task start date, task duration, and resource name. On the righthand side of the chart is a modified bar graph where each task is a horizontal bar organized in a cascading hierarchy as time progress. The Gantt chart chart and draw arrows between tasks to show what order the tasks must be created in; however, the Gantt chart produces a more flat graph that does not show off the dependencies of tasks as well as the PERT chart. The visual clutter of a Gantt chart can be minimized to a great extent by nesting the tasks into a hierarchy of task, subtask, sub-subtask, etc. Microsoft Project allows for a total of nine levels of task nesting. 160 Chapter 10: The Project Plan A Gantt chart from Microsoft Project In my experience in game production I have found the Gantt chart to be crucial and the PERT chart fun. By fun I mean that the PERT chart is so easy to digest visually that seeing the key tasks getting completed and checked off as the project heads towards completion is a visual treat. The problem with the PERT chart is again you must reduce the task resolution to just the highest level tasks. This results in relatively chunky task descriptions like “implement 3D engine,” “script campaign one,” and “alpha test,” and these relatively chunky tasks are actually composed of many tasks spread over a great deal of time. The PERT chart becomes dissatisfying when you want to mark off a PERT box when something is 90 percent complete even though the final 10 percent will not be completed for some time. For this reason I do not use PERT charts for my own projects. (debate rages but aim for between .25 day to 3 days in your task resolution). An example of a poor entry would be 3D engine, 4 months, Bob. This task is poorly described for two reasons: The first is the name itself, 3D engine. What does that mean? Test it? Design it? Debug it? Implement it? Review it? Break it? Fix it? Vague project task names must be attacked ruthlessly and reduced to a lean, aggressive name like Create static design of the core 3D engine. The second thing wrong with this task is that it is four months long! Good grief, why are we even putting together a schedule? How will it serve to measure progress when we can only look Bob up after 15 weeks and ask if he thinks he will make it next week? With such coarse resolution we are simply not getting enough incremental task progression data to have a meaningful analysis of whether the project is tracking. For if we are not tracking, maybe we should cut features in the 3D NOTE: Please see Chapter 20 for a quick survival guide to Microsoft Project. engine, or maybe we need to add another programmer to work on the Focusing on the Gantt Chart custom shaders, or maybe we should kill the new 3D engine altogether and So how exactly do we create a Gantt make do with the previous engine or chart? Obviously we need to know integrate a commercial 3D engine. All what the tasks are, who is going to do them, and how long they will take. The of these tough choices can be uncomideal Gantt chart entry is a single, clear, fortable or even impractical for you and your project, but these choices are discrete task with a short duration Chapter 10: The Project Plan 161 certainly not more comfortable when Bob has been working for 15 weeks and then admits that the 3D engine turned out to be tougher than he thought and that in four more weeks he will know more! There is a time and place for coarsely defined Gantt charts—very early in the project when you are defining your business parameters. At this time it is useful to block out your project with these coarse task granularities to get an idea of how many people you will need and about how long it will take to get the job done. This protoGantt chart can then be used iteratively to help define the costs of the project while they are still fairly malleable in the early project negotiation phase. In the ideal world a publisher would sign up a project and pay for three months of preproduction to determine the detailed project schedule; this rarely happens. Instead, you often work on the rough size and scope of a project and then use the early milestones to refine your schedule and kill features to make the project fit into the negotiated costs. I have to warn you, creating these proto-schedules is not a substitute for going through with your full preproduction phases and determining your task estimates in detail! You should also avoid creating a proto-schedule if you have little experience in project planning, or where the game has not yet jelled into a clear vision, or where there are a lot of associated technical risks because you or your team have not developed a similar game. WARNING!—Creating proto-schedules should only be done by experienced project planners who have managed similar projects and where the game scope is well understood. Using the Technical Design Document The technical design document is supposed to have the information for the technical tasks. Depending on how you organize your team members, the game design document, the technical design document, or a stand-alone art asset document will describe the art tasks. Wherever the information is coming from, as you sit down to enter these tasks and time estimates into Project, you will discover that these tasks are not ready for immediate entry. For instance, the 30 luminosity maps needed for your starships will be listed as 45 man-days from your art director. Should you enter that as a single task named luminosity mapping, 45 days, artists? No you should not; that would be creating a vague task entry like the previous 3D engine example. Will you have all of your artists working on this for 45 days? Will you burn one of your artists on this tedious task? Do you need all of the luminosity maps done at the same time? These are the questions you need to ask yourself as you translate the task estimates from your leads into your schedule. For a task like this I would write up 30 1.5-day tasks and distribute them evenly across the artists I had available to perform these tasks (in my management style, if there is something boring and repetitious, I generally distribute the tasks evenly, perhaps a bit heavier on the junior team member). Getting ahead of myself into a discussion of risk management and task dependencies, I would schedule these repetitious, low-risk tasks towards the end of the project with perhaps some sample luminosity maps done early on to verify we understood 162 Chapter 10: The Project Plan the production path and time estimate to create the maps. These 30 1.5-day tasks would be an eyesore to look at if we were to enter them flat into the schedule. To handle that bit of dust, sweep these 30 entries into a supertask named create luminosity maps. This way we can view this individual information easily by expanding the super task create luminosity maps and hide it when it is not of immediate interest. Each of the 30 subtasks should also refer to the specific starship that the map is for or at the very least be uniquely identified as in create luminosity map for Federation Enterprise-E, 1.5 days, Ed. It will be difficult to always break down tasks into their proper subtasks. For example many times you will get a reasonable-sounding task like investigate pixel shaders, 3 days, Tom. It has a fairly clear verb—investigate—right? Well, does it mean Tom will spend three days on learning what is going on with pixel shaders and then move on? What is the deliverable for this task? Will Tom merely know more about pixel shaders or are you expecting to implement pixel shaders? Will the artists need to perform additional work to support the pixel shaders if Tom gets them done? I recommend this task be broken down into the following tasks: Investigate the A poorly broken down task—too long The previous task broken down into 30 bite-sized 1.5-day tasks distributed to two artists, with an early phase to determine the validity of the task estimate for both artists, rolled up under a super-task. Chapter 10: The Project Plan 163 As you enter the data you will not only need to break up the tasks into smaller tasks, but you will also need to spend a moment chewing on the time estimates being reported by your team members. There is a lot of debate in the community about padding tasks by two times or three times to count for the chronic underestimation that developers are prone to make. I fundamentally disagree. I think it is a very bad thing for the development team to think in terms Breakin’ down tasks of “programmer-hours” and feel assured that their management lead will take responsibility for padding the Task Granularity and Task Leveling schedule to accommodate their optiTask leveling is the act of distributing mism. If you think about this for a the workload across your developers so moment, it does seem ludicrous to take that no one developer is stuck holding the developer’s estimate and instituup the show while the rest kick back at tionally lie and come up with another the beach. Task leveling is a difficult number. I believe the reason organizaand imprecise business. No two develtions do this multiplying technique is opers on your team will produce code, they have found that taking the develart, or other game development bits at opers estimates has resulted in the same rate and with the same level previous projects slipping and going of initiative and independence. Task over budget. The answer is the develtracking is such a central activity of opment process is flawed, and that is game production that the next chapter why the project is late, not because a is dedicated to its discussion. However, developer makes poor estimates. How here in the planning stage we can set can a project succeed when such arbiourselves up for success later by plantrary estimates are tossed around? ning our task leveling now. In the feasibility of pixel shaders, 1 day, Tom; Implement core support for shaders, 1 day, Tom; Implement simple shader for ripple effect, 1 day, Tom; Determine what additional work the Artists must perform, .25 day, Tom; and then wrap up all of these tasks under a super-task named implement ripple shader. Picture in your mind that it is your job to view each and every incoming task as a crystalline rock that you examine closely, looking for the fissures that represent the subtasks inside of the project. Then you grasp the task firmly in your hands and break it up along these fissures. previous section I stressed breaking down large, vague tasks into clear, crisp, small tasks; it turns out that breaking tasks up into crisp bite-size chunks is also critical for effective task leveling. By breaking up the tasks into their smaller pieces you will not only see more clearly just how much work you have to do, but you will also be able to better analyze how to distribute your tasks across your company. How Long Will That Task Take? 164 Chapter 10: The Project Plan So how do you get good time estimates? First of all I do not make creating the time estimates my responsibility as the project manager; I make that the developers’ responsibility. Is this just a semantic nuance? No, the way to success is to push down to them the responsibility, the authority, and the accountability to create their own time estimates. I will not be performing the work; they will. Your team members are not just coders or pixel pushers; they are game developers. Grow your organization so they understand that creating quality estimates is part of their job and that they need to make an estimate they can live with. Will pushing estimating down to the team members work? What about the new artist; does he know how long it will take to texture the level? How about the AI programmer; now that he has been tasked to create the networking code, how will he come up with a quality estimate? I am not saying that the senior team members such as the art director and the lead programmer as well as the project manager should not participate and help develop the estimates. What I am saying is that my team performs best when they are working under a schedule they drafted. It may look like I have not solved the time estimate problem; it may look like I just moved it down to the developer, but that is too casual a statement. When you walk up to Sally and ask her how long it will take to create a mission editor for the game, she might reply with a shrug and a soul-searching glance at the ceiling and come back with an estimate of two months. This is a low-quality estimate. Much better is to walk up to Sally and say to her, “I want you to think about what it is going to take to get the mission editor done; specifically, I want you to review the technical and game designs for the mission editor and break it down into a task resolution of one to three days each and enter your tasks into Microsoft Project. Would Friday be okay with you to review your schedule?” This is much stronger because you gave a clear task of getting her area estimated and put into a schedule, and you told her how to get it down with the comments on the time resolution and Project. You also gave a firm date and gave every indication that it is her responsibility. So what do you do when developer estimates are too short or too long? You are the project manager, and you have responsibility for running the project. While the buck stops with you, your job is to get the right people matched to the right tasks with the proper tools and resources to get the job done. It is the artists and the art director who are responsible for the art estimates. You said that before, Erik, but what do I do with a time estimate that is clearly too short? I want you to review every time estimate for a reality check, a second opinion, and for your own benefit to build up a better mental map of how long the myriad of development tasks take. What I suggest you do with a short time estimate is interview the developer and/or lead for that section and ask them why they thought they could accomplish it so quickly. Maybe you will find out something you did not know; that would be a good thing. Maybe they will shrug and admit they didn’t give it enough thought. Or maybe it is a feature they very much want to Chapter 10: The Project Plan 165 see get done and do not want to see it cut so they are “selling you” the feature. Estimating Research Tasks How do you estimate how long it will take to get something done that no one has done before, or no one in your orgaShort Time Estimate Possibilities nization has done before? Perhaps there If the developer did not give the estiis little in the way of journal articles or mate enough thought, then simply kick books to give direction. How do you it back for a revision. If you simply estimate how long one of these tasks were not aware of something that will will take? The first step is to break make the task quicker to complete— down the research task into as many no problem, accept the estimate. How- small, discrete tasks as possible as we ever, when it turns out they are selling discussed previously. An example: you on a feature, this could be a probElaborate on a task named research lem. First of all, this means you have a pixel shaders and modify the task to a flaw in your schedule that needs to be series of tasks like the following: corrected or the rest of your schedule 1. Install video card with pixel shader will be affected. The hard part is that support your developer is selling you this fea2. Install DirectX 8.0 ture because she really wants to see it 3. Review DirectX 8.0 sample shader get in the schedule and she felt she code needed to underestimate the task to get 4. Create stand-alone test bed to it on the schedule. You have three explore pixel shaders choices: Kill the feature, allow the fea- 5. Create water effect through pixel ture, or allow a fixed amount of time to shaders work on the feature. Each situation is 6. Create fire effect through pixel unique, but I tend to ask the developer shaders why she thought it was so important to 7. Design architecture for the 3D implement the feature. If she does a engine to utilize pixel shaders reasonable job convincing me it is a 8. Implement pixel shader desirable feature but I cannot afford to architecture rearrange the schedule to fit in the true 9. Unit test the pixel shader code time for this task, then I will encourage 10. Implement fire effect—attach to the developer to drop the feature. Many fireball spell times the developers will be passionate 11. Implement water effect—attach to about getting it done and will propose water blast spell to keep the time estimate to what the 12. Test the fireball spell schedule can afford, and they will work 13. Test the water blast spell hard to squeeze it in. This I feel is fair; By breaking down research pixel shaders the manager should not create schedules that require overtime, but I do feel into 13 subtasks, we can put good estimates on most of the tasks. Only task comfortable with developers working as many hours as they like to create the number four, Create stand-alone test bed to explore pixel shaders, looks like a type highest quality game they can. 166 Chapter 10: The Project Plan of research that resists being nailed to a firm time. The solution here is to set a time box, a fixed period of time you will allocate to the task. At the end of the time box you will either be done with the research or it will have turned out to be too expensive to continue. Mm, yes, what is that? How can you walk away from something not done? Well you might have to. Say you have 15 months to get your game done with ten developers, five of them programmers. Allowing three months for preproduction and three more months for testing and transition leaves nine production months or a total of 45 programmer months. This is your time budget; if the rest of your project is looking like 44 programmer months, then you have just one month left over to play around with your pixel shader. Put a time box of one month around the pixel shader work. These are the types of hard decisions you will have to make if you are going to run your project on budget. Oh, so the pixel shaded spell effects were a core feature? Everyone thinks that is what it will take for your Diablo killer to make it over the top? After the one month passes and you are still not done, would you feel it is still so important a task that you would allocate more time to get it done? If so, then your original time box was not honest by taking into account your priorities. Time boxes only work if you stick to them. If the feature is really that important, then you should have allocated two months or three months. When setting a time box, set the maximum amount of time you are willing to spend on a feature of that priority level. Too many times when we are deciding whether or not to implement a feature, we just ask how cool it will be or whether the competition has it, in the end deciding to implement the feature for a number of compelling reasons. Remind yourself that the great games all have a slim feature set that was executed with excellence. Think about that cool research-intense feature; do you really need it? Only a project with unlimited financing and no requirement for shipping can afford to implement features without asking the cost. Think of time boxes as stones in a stream where the rest of the tasks flow around these blocks of time; a few rocks are cool, many rocks is a stretch of rapids, and a wall of rocks is a dam. Determining a task’s priority deserves its own subsection. Task Prioritization Assuming you and your team are creative folks and that you are making a game with a budget of time and money, you will always face a situation where you have too many ideas for cool features and not enough time to implement them. You are then faced with the job of prioritizing your features to be sure you get the critical features accomplished at the right expense of the less important features. I have a reliable method for task prioritization: First discover all the absolutely required overhead tasks your team must accomplish or you will not even have a shipping game. These tasks include preproduction, beta testing, getting hardware manufacturer approval, getting licensor approval, creating milestones, and responding to milestone feedback. These are what I call zero-level tasks. Also do not forget to estimate the number of holidays, vacation, and sick time your team members will take, and make a Chapter 10: The Project Plan 167 reasonable provision for turnover (I use one developer for every ten developers per year). Subtract all of this nonproduction time from your overall schedule; this will leave you with the real production time you have to work with. Enter all of the zero-level tasks into your Microsoft Project Gantt chart. (See Chapter 20 for a quick overview of Project and such tips as customizing your team’s calendar.) The next step is to take your design documents and toss every task into one of three buckets: core tasks, secondary tasks, and tertiary tasks. Take your time with this. I highly suggest discussing the relative priority of the tasks with various team members to build consensus and to have some solid feedback. Now that you have your three buckets, lay out all your core tasks in Microsoft Project using good task articulation techniques, and assign the tasks to the resources on your team. Now that you have your zero-level tasks and your core tasks entered into your Project file, use the project-leveling tool to see how the zero-level and core-level tasks will lay out over time. If you were conservative with what you labeled as a core task, then you should have some extra time left over to start plugging in your secondary tasks. However, if the buckets ended up with too much to do for even your core tasks on the first pass through, then you have to prioritize your core tasks and convert enough of them to secondary to make up the difference. This means that the secondary and certainly the tertiary tasks are unlikely to be completed if you are having trouble accommodating even the core tasks. JARGON: Leveling is the term in project management for the related tasks of seeing how the tasks will lay out over time and how loaded each of your resources are, and the process of distributing tasks across your team to achieve a more even workload. How do you prioritize the core tasks when you already consider them core? First realize they cannot all be core. A rigorous development process requires developing good time estimates, and you have done that; now you are looking at a body of tasks that are core and features you really want but do not have the budget for. Perhaps you can make a strong enough case for these features to get approval to expand your project’s budget. If you can do that, great—problem solved. If you are still holding to your original budget, then let me show you how I do low-level task prioritization. It’s a crude method really, but it is effective: Take all your core tasks and enter them into a spreadsheet (use Excel) with a column labeled priority next to each task and a task time estimate. Now quickly run down your tasks, reading the task names and saying out loud the first gut-level priority that occurs to you for that task such as 7 or 3 or 10 if it is really critical. Go down your whole column of tasks whether it is ten core tasks or 200. Do this first pass quickly; taking longer will only make it harder. Now you will have a first pass priority for all of your core tasks. Have the spreadsheet software sort the core tasks from most important descending to least important. If you are like me, then you will see that you have stubbornly labeled too many tasks with a 10 or 9, and too few tasks have earned the label of 3 or 2. The way to solve this is to allow yourself 168 Chapter 10: The Project Plan Bug ID 2929 2953 2979 2987 3031 2561 2607 2609 2617 3110 2624 2632 2633 2637 2641 609 2058 2119 2701 2763 2765 2780 2784 2797 2799 2817 2826 2841 2868 2869 2880 2309 Bug Title CD-Key AM FL Y Team-Fly® only three level 10 tasks, three level 9 tasks, and so on. Start at the first item labeled 10 and take your time thinking deeply about the feature, discuss it with your team if you have to, but one by one you are going to demote your 10s to 9s until you are left with just three must-do 10s. Repeat this process all the way down your list. The mathematically astute will notice that this specific labeling system will fail if you have over 30 tasks. The exact labeling scheme is not important; it is just important to force yourself to make these prioritization choices. You could use the numbers 999 to 0, you could use the alphabet, or you could use a three-letter alphabetic core like AAA to DDD; whatever you use just leave yourself a set of three tasks at each prioritization level. The size of your task set should be roughly one-tenth of the overall numbers of tasks to be prioritized. Now just draw a line where you run out of time for core tasks, and toss the lower priority tasks in with your secondary tasks. Priority SP - Klingon Campaign - Beginning Stardate is 112400.1, twice what it should be Dynaverse - Fleets do not have accept / forfeit options in mission panel Dynaverse - Romulans can transfer in Borg officers Global - Freighter Convoys do not have escorts Campaign Screen - Player's ship gets stuck in Hex Tactical Sim - Fed vs Fed fights Dynaverse - Jumped from Lt. Commander ranking to a Fleet Admiral ranking Dynaverse - Ten turn countdown results in stuck in Hexes Dynaverse Campaign Screen - Fleet leader is not clear Dynaverse - Can make movement bar disappear when leaving a Hex with refit Dynaverse - While being attacked, attacking another will teleport player DYNA - Map Screen not refreshing on completion of Mission Campaign Screen - Ships inconsistent for Convoy between Attacking or Defending SP - Campaign Screen - States we are partners with the Contested Sector Dynaverse - Cause of numbers appearing after player names in the chat box New Conquest - Music stutters and pointer freezes loading new Conquest Global - When AI forfeits it stays in the Hex Dynaverse - Role of convoys Access Server not using list of IP addresses SP - General - Player can initiate a battle then auto move kicks in SP - General - Player can be attacked when auto move kicks in Hex information should appear in game display SP - General - There needs to be a message when auto move is enacted Dynaverse - "Stand by for mission briefing" panel repeats text Dynaverse - Spectate does not work Campaign Screen - All races should begin equally allied to Neutral Hexes Dynaverse - Able to access buttons (campaign screen) anywhere on Hex map Dynaverse - Enemy AI kills fleet member AI - Defeat with prestige Dynaverse - Borg cubes appear very infrequently in Shipyard Dynaverse - Destroyed enemy ship reappears on Hex map immediately Dynaverse - Hex changed color to red when Fed was leader and Kling was member TE Chapter 10: The Project Plan 169 2318 1681 2452 2981 951 2023 1790 Tactical Sim - Visioneer opinion on buying Starbases Dynaverse - Officer advancement text cut off in message board AI doesn't know to go back to a repair station to repair hull Dynaverse - Severely damaged AI attacks healthy players Dynaverse - AI does not team up properly in a Hex Dynaverse - Able to join missions in old Hex after leaving for new Hex SP - Tactical Sim - Able to click on map behind "Campaign Over" screen The list of bugs and issues unprioritized Bug ID 2929 2953 2979 2987 3031 2561 2607 2609 2617 3110 2624 2632 2633 2637 2641 609 2058 2119 2701 2763 2765 2780 2784 2797 2799 2817 2826 2841 2868 2869 2880 2309 2318 1681 2452 2981 951 2023 1790 Bug Title CD-Key SP - Klingon Campaign - Beginning Stardate is 112400.1, twice what it should be Dynaverse - Fleets do not have accept / forfeit options in mission panel Dynaverse - Hex changed color to red when Fed was leader and Kling was member Dynaverse - Romulans can transfer in Borg officers Global - Freighter Convoys do not have escorts Campaign Screen - Player's ship gets stuck in Hex Tactical Sim - Fed vs Fed fights Dynaverse - Jumped from Lt. Commander ranking to a Fleet Admiral ranking Dynaverse - Ten turn countdown results in stuck in Hexes Dynaverse Campaign Screen - Fleet leader is not clear Dynaverse - Can make movement bar disappear when leaving a Hex with refit Dynaverse - While being attacked, attacking another will teleport player DYNA - Map Screen not refreshing on completion of Mission Campaign Screen - Ships inconsistent for Convoy between Attacking or Defending SP - Campaign Screen - States we are partners with the Contested Sector Dynaverse - Cause of numbers appearing after player names in the chat box New Conquest - Music stutters and pointer freezes loading new Conquest Global - When AI forfeits it stays in the Hex Dynaverse - Role of convoys Access Server not using list of IP addresses SP - General - Player can initiate a battle then auto move kicks in SP - General - Player can be attacked when auto move kicks in Hex information should appear in game display SP - General - There needs to be a message when auto move is enacted Dynaverse - "Stand by for mission briefing" panel repeats text Dynaverse - Spectate does not work Campaign Screen - All races should begin equally allied to Neutral Hexes Dynaverse - Able to access buttons (campaign screen) anywhere on Hex map Dynaverse - Enemy AI kills fleet member AI - Defeat with prestige Dynaverse - Borg cubes appear very infrequently in Shipyard Dynaverse - Destroyed enemy ship reappears on Hex map immediately Tactical Sim - Visioneer opinion on buying Starbases Dynaverse - Officer advancement text cut off in message board AI doesn't know to go back to a repair station to repair hull Dynaverse - Severely damaged AI attacks healthy players Dynaverse - AI does not team up properly in a Hex Dynaverse - Able to join missions in old Hex after leaving for new Hex SP - Tactical Sim - Able to click on map behind "Campaign Over" screen Priority A C B C B B A B C A C C Prioritization starting (use A, B, C or 1, 2, 3) 170 Chapter 10: The Project Plan Bug ID 2929 2953 2979 2987 3031 2561 2607 2609 2617 3110 2624 2632 2633 2637 2641 609 2058 2119 2701 2763 2765 2780 2784 2797 2799 2817 2826 2841 2868 2869 2880 2309 2318 1681 2452 2981 951 2023 1790 Bug Title CD-Key SP - Klingon Campaign: Beginning Stardate is 112400.1, twice what it should be Dynaverse - Fleets do not have accept / forfeit options in mission panel Dynaverse - Hex changed color to red when Fed was leader and Kling was member Dynaverse - Romulans can transfer in Borg officers Global - Freighter Convoys do not have escorts Campaign Screen - Player's ship gets stuck in Hex Tactical Sim - Fed vs Fed fights Dynaverse - Jumped from Lt. Commander ranking to a Fleet Admiral ranking Dynaverse - Ten turn countdown results in stuck in Hexes Dynaverse Campaign Screen - Fleet leader is not clear Dynaverse - Can make movement bar disappear when leaving a Hex with refit Dynaverse - While being attacked, attacking another will teleport player DYNA - Map Screen not refreshing on completion of Mission Campaign Screen - Ships inconsistent for Convoy between Attacking or Defending SP - Campaign Screen - States we are partners with the Contested Sector Dynaverse - Cause of numbers appearing after player names in the chat box New Conquest - Music stutters and pointer freezes loading new Conquest Global - When AI forfeits it stays in the Hex Dynaverse - Role of convoys Access Server not using list of IP addresses SP - General - Player can initiate a battle then auto move kicks in SP - General - Player can be attacked when auto move kicks in Hex information should appear in game display SP - General - There needs to be a message when auto move is enacted Dynaverse - "Stand by for mission briefing" panel repeats text Dynaverse - Spectate does not work Campaign Screen - All races should begin equally allied to Neutral Hexes Dynaverse - Able to access buttons (campaign screen) anywhere on Hex map Dynaverse - Enemy AI kills fleet member AI - Defeat with prestige Dynaverse - Borg cubes appear very infrequently in Shipyard Dynaverse - Destroyed enemy ship reappears on Hex map immediately Tactical Sim - Visioneer opinion on buying Starbases Dynaverse - Officer advancement text cut off in message board AI doesn't know to go back to a repair station to repair hull Dynaverse - Severely damaged AI attacks healthy players Dynaverse - AI does not team up properly in a Hex Dynaverse - Able to join missions in old Hex after leaving for new Hex SP - Tactical Sim - Able to click on map behind "Campaign Over" screen Priority A C B C B B A B C A C C B A A B C C C B A A A C B A B B B B C A C C C C B B C All tasks have received a priority. Chapter 10: The Project Plan 171 Bug ID 2929 2607 3110 2637 2641 2765 2780 2784 2817 2309 2979 3031 2561 2609 2633 609 2763 2799 2826 2841 2868 2869 951 2023 2953 2987 2617 2624 2632 2058 2119 2701 2797 2880 2318 1681 2452 2981 1790 Bug Title CD-Key Campaign Screen - Player's ship gets stuck in Hex Dynaverse - Ten turn countdown results in stuck in Hexes DYNA - Map Screen not refreshing on completion of Mission Campaign Screen - Ships inconsistent for Convoy between Attacking or Defending Access Server not using list of IP addresses SP - General - Player can initiate a battle then auto move kicks in SP - General - Player can be attacked when auto move kicks in Dynaverse - "Stand by for mission briefing" panel repeats text Dynaverse - Destroyed enemy ship reappears on Hex map immediately Dynaverse - Fleets do not have accept / forfeit options in mission panel Dynaverse - Romulans can transfer in Borg officers Global - Freighter Convoys do not have escorts Tactical Sim - Fed vs Fed fights Dynaverse - While being attacked, attacking another will teleport player SP - Campaign Screen - States we are partners with the Contested Sector Dynaverse - Role of convoys SP - General - There needs to be a message when auto move is enacted Dynaverse - Spectate does not work Campaign Screen - All races should begin equally allied to Neutral Hexes Dynaverse - Able to access buttons (campaign screen) anywhere on Hex map Dynaverse - Enemy AI kills fleet member AI - Defeat with prestige Dynaverse - AI does not team up properly in a Hex Dynaverse - Able to join missions in old Hex after leaving for new Hex SP - Klingon Campaign - Beginning Stardate is 112400.1, twice what it should be Dynaverse - Hex changed color to red when Fed was leader and Kling was member Dynaverse - Jumped from Lt. Commander ranking to a Fleet Admiral ranking Dynaverse Campaign Screen - Fleet leader is not clear Dynaverse - Can make movement bar disappear when leaving a Hex with refit Dynaverse - Cause of numbers appearing after player names in the chat box New Conquest - Music stutters and pointer freezes loading new Conquest Global - When AI forfeits it stays in the Hex Hex information should appear in game display Dynaverse - Borg cubes appear very infrequently in Shipyard Tactical Sim - Visioneer opinion on buying Starbases Dynaverse - Officer advancement text cut off in message board AI doesn't know to go back to a repair station to repair hull Dynaverse - Severely damaged AI attacks healthy players SP - Tactical Sim - Able to click on map behind "Campaign Over" screen Priority A A A A A A A A A A B B B B B B B B B B B B B B C C C C C C C C C C C C C C C And now they are sorted. Resource Leveling In a real schedule it will be much more likely that the bulk of your core tasks will fit in your schedule but one or two of your developers have been overscheduled. If at the end you have leveled the tasks the best you can and you are still left with an overloaded resource, then you will have to take their tasks and run them through a rigorous task prioritization session with the spreadsheet as I described above. Find the true core tasks and relegate the rest to a secondary phase. 172 Chapter 10: The Project Plan Hold on to your secondary and tertiary task lists. When you create schedules that your developers can accomplish, they will appreciate it and respond with timely execution. It is common for them to be excited and push themselves to see how many of the secondary and tertiary tasks they can pick up. See the next chapter on task tracking for more tips on how to keep your team humming along. If you were conservative with your original labeling of core and secondary tasks and you did have a surplus of time, or if you had a surplus of time with part of your development team, then now is the fun time of piling on your secondary tasks until you are out of time with your resources. Use the detailed task prioritization method on the secondary tasks if you are having trouble deciding which of the secondary features you will implement. Task Dependencies difficult job. A rather tedious job, I admit, entering tasks into Project, but mechanical and straightforward. Project planning enters a new level of complexity when task dependencies are taken into account. Task dependencies develop when one task depends on the completion of another task. A great example is all of your production tasks should be dependent on the completion of the preproduction milestone. After you have entered all your zero-level and core-level tasks (as well as any secondary tasks you found time for) you will now need to draw dependency lines between tasks that are truly dependent on each other. In Microsoft Project there are two easy ways to link tasks: One is to draw a link between two tasks by simply left-clicking on one task and dragging the pointer to another task and letting go. The other method is to simply type in the task ID number in the Predecessors column. JARGON: Dependent tasks are two tasks that are linked such that work on task B cannot start without the completion of task A. This makes task and resource leveling more complicated. Creating the schedule is not too bad so far, is it? Painful decisions about what will be a core task and what will be a secondary task is about the only An example of linking tasks Chapter 10: The Project Plan 173 Try not to link too many tasks; specifically, link only tasks that are dependent on each other. Some people, out of frustration with Project’s leveling algorithm, start linking all kinds of unrelated tasks to get their project to flow in time the way they plan for production to follow. In other words, do not use the task dependency links to establish task priorities. Microsoft Project has a field for task priority for every task entry. Now run the Project leveling tool; if you are very lucky, all of your tasks will politely level out and none of your developers will be overscheduled due to the task dependencies you entered. The resource usage screen; the red numbers indicate an overallocated resource. Setting the priority level of a task from 0 to 999 Most of the time, however, entering task dependencies will cause one or more of your developers to go over schedule. Now you will earn some of your salt; this is an area where it is difficult to give general advice that will apply to your specific overallocations due to dependencies. You first need to study the Gantt chart and the resource usage charts to understand what your dependency problem is all about. In all cases your developer was okay before the dependencies were drawn in from the earlier stage where you determined the zero-level and core tasks. So looking back up the chain of tasks you will see one or more tasks that are holding up the show for your overscheduled developer. This will create a pocket of free time for this same developer earlier in the schedule as he is stalled waiting for work. Now the most elegant solution would be if the work he is waiting for is something he could do himself; then you can simply assign it to him and fix the dependency problem. And in turn you will need to take some other work off this developer and exchange it with the original developer who was the bottleneck before. The resource usage report shows holes and gaps indicating a problem of one resource waiting on another. The gaps filled by task reassignment 174 Chapter 10: The Project Plan The Gantt chart of the fixed schedule If exchanging and rearranging tasks still leaves you with a pocket of dead time and a later overallocation of one of your developers, then you will have to trim off the overallocation and bring up a secondary task to fill the void. That will be the best you can do if all other efforts to exchange, rearrange, and distribute the overallocated tasks fails. The Top Ten Risks Document By far the schedule is the major deliverable of the project plan, but there is one more document that is critical: the top ten risks document. For this document enumerate the ten most significant risks to the project. Choose only ten items; a longer list will lose its focus. With each of the risk items also list what actions you have taken or will take to contain or address the risk. Hopefully you will be able to create a DATE: Rank 1 2 3 4 5 6 7 8 9 10 3/1/02 Risk Mission design slips User interface design slips QA resources added late to the project Voice-over assets delivered late Feature creep Late solicitation to beta testers Server stability Design process overly distributed Overextended use of overtime UI overcorrected for mass appeal positive solution to each of your risks; however, that is not a requirement. The important thing is to create a short, focused document with one through ten of your risks that you can share with your executive management and with your development team. This document should be maintained with delivery of each of your development milestones from preproduction to the game’s release. You will then see a much greater awareness from your executive management of the risks, and you should be able to address these risks with more energy. In fact, these short top ten risk documents are the most effective way I have found to communicate to my executive management just how much I need something: another programmer, two more artists, or timely audio asset delivery. Effect slip slip low quality, slip slip slip slip low quality washed out quality slip, low quality lack of distinction Solution Finalize Missions ASAP Finalize UI ASAP More QA Resources earlier Finalize dialogue ASAP Stop adding features Submit to beta testers earlier Create testing tools Reduce number of authorized designers Address slip issues Fewer designers A top ten risks document Chapter 10: The Project Plan 175 The Non-Zero Chance of Delivery At the end of the day your job as the project planner is to create a plan for how long it will take to get the job done, not the earliest possible date with a non-zero chance of delivery. This page intentionally left blank Chapter 11: Task Tracking 177 Chapter 11 > > > > > > > > > > > > > > > Task Tracking Production Begins—Now What? Congratulations! You have made it through preproduction, your project is approved and funded, now all you have to do is follow your plans and make your killer game! This is a short chapter on how to track the completion of tasks and how to get the most productivity out of your team. Task Visibility You cannot just print out copies of your Gantt chart then surf the web for a year while your people make the game. This will not work. Even if you made the most professional Gantt chart ever, printed out in color and spiral bound. Passing out these project binders to everyone is an excellent idea, but if that is all you do to make your developers aware of their tasks and their team’s tasks, then you will fail to get anywhere near your team’s full production potential. I am not saying people are inherently slothful, no, quite the opposite— almost everyone I have met in the industry prides himself on his ability to work hard under a crunch to produce a hit game. It is just that left to their own devices, your folks will probably work on what tasks are most interesting to them unless they are reminded of where they are on the schedule and where everyone else is on the schedule. The key is to make the tasks visible. Team members need to know in detail what they should be doing, and they need to know how the work they are doing correlates with others on the team. They need to feel a part of the team and share a sense of urgency to get the job done. As tasks are completed it should be communicated as quickly as possible to the rest of the team to give them a sense of the pulse of the project. I have some specific techniques to share with you to achieve strong task visibility. The Wall I have an effective, low-tech way of getting task visibility out to the team members: I print out the Gantt chart and/or task lists and pin them up on a central wall in our workspace. Software solutions such as Microsoft Team Manager and intranets to publish your schedules and tasks are distinctly 178 Chapter 11: Task Tracking unsatisfactory for two reasons: One, your developers need to remember to even open up the document or visit the site, and two, monitors are too small to show a whole Gantt chart, denying your team the appreciation of the project progress as a whole. It is easy to print out your schedule and pin it up. I recommend just displaying task name and ID, start time, end time, who is assigned to it, and any predecessor tasks on the left-hand side and the Gantt chart on the right-hand side. You should use the widest time setting you have wall space for; when a schedule is scrunched up into just displaying quarters or months on the Gantt window, you are not getting any real-time information. Now I make a requirement to my developers that they come out to the Gantt chart and mark the tasks off themselves. I do not mark them off even if I know they have been completed. This is to get the developers to come out and find their place in the schedule, mark off with a bit of pride what they have finished, and then look ahead to see what is coming up. Developers will almost always take the time to then look over the whole schedule to gauge how are they doing compared to other team members. When I first started using this method of task tracking it was considered somewhat controversial. Some people asked me privately if this was a good idea. If someone were not accomplishing his tasks on time, would it not be demoralizing for him if this were made public knowledge? Would not that developer feel more comfortable staying in his office and explaining privately why he is behind in the schedule? Bah! My first assumption is that everyone on my team is a professional, and even on an off day all would want to be treated as professionals. Why would protecting their comfort be of higher importance than getting our tasks done in a timely manner? If people are tasking late, they must have a reason. Was it illness? Jury duty? Task underestimation? Were they distracted helping another team member on another problem? All of these are legitimate reasons for being late and certainly nothing to cause embarrassment or discomfort. On the other hand, if they are late because they were just goofing off, then I feel comfortable making them squirm in front of their other team members and letting them know they have let the team down. Knowing that the whole team is aware of what they are and are not getting done goes a long way to inhibit goofing off. A healthy bit of competition develops with a good wall. Assuming your schedule was a sane schedule and manifestly fair in the time allocated to the tasks to be completed, your team will be in a high morale state to begin with. I use brightly colored highlighting markers to mark off the tasks. Your developers will come out at the end of the day to mark off what they got done then look ahead for something simple to do before they go home—bam! Another task is taken care of! This competition effect will give extra momentum to your whole project. It will give your developers a meta-game to push themselves, and they will enjoy it. Another benefit of the wall is that it makes a great piece of visual feedback to the executive management team. They look over the wall and see all the marked-off tasks spanning 25 square feet of wall space and nod to them- TE AM FL Y Team-Fly® Chapter 11: Task Tracking 179 selves and move along. Do not underestimate the importance of reassuring your management that you are respecting their time and money and are making measurable, steady progress. If you are working in a large studio or in a publishing house, the other teams will see what you are doing and think you are obviously trying to get attention. So what—you are trying to grab management’s attention. There is no glory in obscurity. Encourage your team members to go ahead and write any unanticipated tasks they had to complete onto the wall’s task lists. This will help team members who might be falling behind in tracking due to being sidetracked by tasks that were not originally on the schedule. While it may seem crude to scrawl new tasks on the list, it is legitimate. You are after the maximum visibility for all tasks, not just the ones you were smart enough to think of earlier. When the time comes to update the schedule, the wall charts with the new tasks written on it and the completed tasks marked off will come in handy. Just tear it off the wall and bring it to your workstation where you have Microsoft Project. Journals I have a background in engineering, and while in school we were introduced to the value of a journal to record actions, observations, and data from the lab. The idea is that no effort you make should be unworthy of record. While I admit that when we make a game we are not building a skyscraper or a transorbital spaceship, we are still creating something important and we should take every care we can on the execution of our game projects. The Cult of the Yellow Notebook For the last seven years I have been using yellow notebooks that are about 5" by 8" inches and feature lined paper on one side and quad-ruled paper on the reverse. This format allows me to track micro-tasks and thoughts on the lined side, and use the graph paper for game designs, user interface layouts, and technical designs. I have this notebook open as I work, taking notes whether I am working at my workstation in Photoshop, MS VC++, Project, Visio, Excel, or simply Word. I also take my journal with me to every meeting to record what I need to do and what I need to follow up with. On a shelf in my office are the 40 or so notebooks I have filled so far in my career. These yellow notebooks are a staple that we purchase for all of the employees at Taldren, and we have an ample stock for when people fill theirs up. I am passionate about these notebooks because I have seen countless small tasks fall through the cracks in our overburdened minds—such a waste that the simple act of note taking can fix! About once every two to four weeks I go back through my pages to search for tasks I might have failed to address, and I pull them forward into a new checklist. 180 Chapter 11: Task Tracking Walk Around There is no older and simpler method of task tracking than simply walking around and seeing how people are doing. I try to carve out an hour or two every day to walk around and meet with the individual team members to see how things are going. At this pace I would visit everyone in the company two to four times a month. This lets people know their work is important, and the human connection really shows you care about getting a great game done. When the project hits a tough spot you will find that you want to stay in your office and focus on the burning fires. But it is when the times are smoky that you should make the extra special effort of visiting with your team members. Also be aware that no matter how much you like everyone on your team, there will naturally be some personalities that you enjoy spending more time with than others. Some people might feel slighted so be sure to visit all of your team members, not just the ones you like to talk to. Often it is by walking around that you discover that tasks you thought were the clear responsibility of one developer have been conveniently relegated to the no-man’s land between two developers and have dropped to the floor. This is a great time to clear up such misunderstandings and get these tasks properly assigned. If you ask the right questions and remain approachable, these walkabouts will also turn up the deeper concerns your team members might have felt too uncomfortable bringing up in some other forum or method. Keep your ears and eyes open and talk to your team members. Milestone Orientation Meetings Another useful technique I have found is to kick off each milestone iteration with a milestone meeting to review what everyone is tasked with and what the associated expectations are for their work. I did not start this ceremony until just this year; however, each time I run the meeting I am amazed at how many misunderstandings we are actually carrying around, and this is on a project that has received our most detailed preproduction to date! At these meetings I simply keep everyone in the room as I go through the features and tasks one by one and get a verbal discourse back from the responsible developer to be sure they understand what they need to do and to give them a chance to request clarification. They will also get full visibility for what they need to accomplish in front of the whole team; this goes a long way to fight the impression that so and so does not have much work to do. Praise People Publicly I also take the time to praise individual team members at each of these meetings—not necessarily everyone—but I do try to keep a running tab of who is due for some recognition. While no one I know would admit it, I think receiving praise and recognition from your team and supervisor is a great morale boost, and the lack of praise and recognition can be a significant drain on morale. Chapter 11: Task Tracking 181 There are good books devoted to how best to reward your employees with all sorts of clever ideas from silver nameplates to holiday turkeys, but I think the best is a public thank you. Maintain the Gantt Chart By far the least fun part of project management is updating the Gantt chart. As you sit in front of Microsoft Project, none of the tasks will seem to have been completed on the days you planned. And so if you simply check off tasks as they are completed, you will be left with a schedule that is full of hard-to-move completed tasks that indicate they were completed on the wrong day. These blocked off dates will not be used in subsequent leveling operations, and soon your schedule will look like a mess. No matter how tedious it is, do not put off maintaining your schedule for longer than a month. I have slacked myself and have regretted it every time. It just takes too much time to repair a badly out-of-date schedule. When a schedule is really in bad shape I sometimes just start a fresh Project file. The latest version of Microsoft Project does have one simple new feature: It lets you move completed tasks back and forth in time! A minor miracle, I tell you. In the older versions you would have to unmark a completed task, move it to the time it was completed (or at least out of the way of the current task leveling concern), and then remark it as complete. This only made a tedious job twice as hard as it needed to be. Take the time to enter in completely new tasks that your developers have taken the time to write on the wall. Also take a close look at any open tasks that are refusing to complete despite one of your developers working hard on the task. My bet is that if you look under the hood of that task, you will discover it is composed of multiple tasks, some of which have been completed. Take the time to break up this task into its component parts and give your developer credit for what has been accomplished. Quite often your developers will tell you that this or that feature is 90 percent done and that they clearly had to move on to more pressing tasks for fear of causing stalls in the project. Their judgment is almost always correct in that there was little profit in having them polish up some feature to true shipping quality when there are others waiting for them to finish something else. This is the same as a task that is really composed of subtasks. In this case the subtask is that final 10 percent of polish on the radar, which is unimportant to solve now. Take that 10 percent polish task and enter it into the schedule; just put it further down in time to when you really will take care of the polish task. For larger projects I strongly suggest you delegate to your section leads the input and maintenance of their part of the schedule. This will help them grow a valuable task, and it will help you keep your job sane. To facilitate this I favor using a tree of inserted Microsoft Project files so that each developer can work on his section of the schedule. I discuss this in detail in Chapter 20. 182 Chapter 11: Task Tracking Update the Risks Chart Rounding out the task tracking set of duties is to update the risks chart: Take the time to review your Gantt chart; is it indicating a new problem down the road? Are the artificial intelligence tasks tracking? How is the mission editor? How are the art assets coming along? How is the testing of the multiplayer code coming along? Ask yourself these types of questions as you review the Gantt chart to see if a new risk has developed or perhaps an older risk has risen in priority. Also take a look at the old risks; have some of then lessened in importance or have they faded away altogether? Some new risks may be introduced from your walks around the team or from a daily journal type mechanism or simple email from your team members. Also take the time to review what you are expecting from your third-party vendors. Are they on time? The true impact of a risks document only comes into play when it is maintained like the project schedule. Be sure to visit with your executive management and apprise them of the latest risks. Post these risks in a public place so that all of your team can review them and have an opportunity to respond to them. After all, taking the time to discover your risks is a good idea, but sharing your risks with the rest of the team and management is key to getting focus on the problems. Of course occasionally you may develop a risk that is personal in nature and is not fit for wide dissemination. Use your common sense and discretion when choosing what to post on a wall. Chapter 12: Outsourcing Strategies 183 Chapter 12 > > > > > > > > > > > > > > > Outsourcing Strategies Why Outsource? Many talented folks can be involved in medium to large game projects from the obvious artists and programmers to writers dedicated to dialogue, to motion capture actors, to voice-over directors, to quality assurance leads. Artists and programmers perform the bulk of the labor on a game project, with these other specialized tasks occurring for relatively short blocks of time in midproduction. specialized tasks do not occur as a steady task across the whole project. This means that to be efficient in the employment of these folks with specialized game development talents, we need to either be a large development house with many game projects in simultaneous production, or we need to outsource this work to third-party vendors who will execute these production tasks under our direction. Otherwise, audio and other specialists who cannot be gainfully employed across the duration of a single project would cause a financial burden on our projects. Most game developers would much prefer to have generous budgets in order to hire in-house all of these experts and be able to work more closely with them to achieve the highest level of quality possible. There are a couple of problems with this approach: First of all you are burning prodigious cash whenever you cannot task them directly to your game project; when they are independent contractors you only pay for the work you need to get done. Second, it is difficult to find excellent people to fill these positions. The higher the quality you are looking Layers of game production—games are software with toppings. As can be seen readily in this diagram, a single game project team requires full-time work from the artists, programmers, design, and management; however, the audio, dialogue, voiceover, motion capture, and other 184 Chapter 12: Outsourcing Strategies for, the more likely the individuals would have risen to a key position at another developer or third-party production house or may even be the owners of their own production house. In short, it will take your organization a long time to build up the financial strength to employ multiple teams and find and retain excellent people for the non-core tasks. Almost all organizations outsource to some degree; most publishers outsource game development to developers, and even those that internally produce their own titles outsource a multitude of tasks such as disk manufacturing and payroll management. Now, what are some good strategies and tasks to keep in mind when weighing outsourcing? When to Think About Outsourcing Your outsourcing plan, which describes what work will be outsourced, by what contractor, by what date, and for how much money, should be determined in the earliest parts of preproduction, ideally before the final budget of the project is decided. There is a natural tension here. The project needs an honest preproduction phase to figure out what tasks need to be performed and who can perform them. Many times we are creating new technology, and it will take a bit of experimentation to figure out how a particular kind of asset will need to be created. All of this planning will take a few people a couple of months—varying widely depending on the size of the project—which means this will take money. However, the way game projects work is that the publisher and developer have to come to agreement on what the final budget will be before any money is spent on the project. This requires an unpleasant choice for the developer: Either work without compensation during the preproduction phase to be able to rigorously determine the costs or enter into a fixed bid agreement with the publisher and then figure out how much the project will cost. It is this tension that is a major source of business frustration in the industry and is the root of a considerable lack of profit for all concerned. That is why I have dedicated such a large portion of this book to introducing outsourcing in all of its various forms. Experienced game developers make better educated guesses on the costs of various features and assets due to having been there before. Too often a project manager will arbitrarily budget X dollars for voice-over work and Y dollars for music, only to find that music requires more money and that the voice-over could get by with less money. This is fine if you catch this discrepancy before you approach either the music contractor or the voice-over director, but it is awkward indeed if you have already signed a contract with the voice-over director! This chapter only introduces outsourcing; several chapters in Part IV are each devoted to a particular type of asset for outsourcing. I hope to provide material for you to take advantage of so that you can begin planning your music needs as soon as possible on your project—before the entire budget parameters are fixed. Chapter 12: Outsourcing Strategies 185 What to Outsource In short, you should outsource tasks that are not your core competency and/or are needed for a short period of time in your project. In other words, if your organization is weak at something, hire someone good to do it for you. ples I can think of where the multiplayer was outsourced all ended with abysmal failure due to a lack of communication between the core team and the multiplayer team, as there are just too many interdependencies between multiplayer and single player to sucDo Not Outsource Programming— cessfully outsource this area. The only Exceptions Noted exception that comes to mind is the A big exception to this rule is the procase of Return to Castle Wolfenstein, gramming. You should never outsource an amazing game produced by id Softyour programming tasks on a game pro- ware and developed by Grey Matter ject. A game is software and if you do with the multiplayer portion of the pronot have the expertise to create the ject developed by Nerve Software. This software, then you should hire the pro- worked well because Grey Matter was grammers for in-house production. If working with id Software’s solid Quake you do not have programmers on staff, III engine and could focus on the conyou should not be making a game; make tent creation. Likewise, Nerve had the what you are good at. This is why a lot same solid engine to work with and of publishers have outsourced game could work on multiplayer parts of the development; it is the most difficult and game without needing constant comrisky part of publishing games, and so munication with Grey Matter. Thus, they have externalized those risks to the work was modular and there were game developers. Almost all organizano awkward dependencies between the tions can find a bucket of useful work two projects. for programmers to perform year Taldren has outsourced a couple of round. programming projects: We have had Occasionally I have heard of proexternal folks create missions for jects where the map editor, the video Starfleet Command II, and we have had compressor, or some other modular folks create a ship editor for SFC II. For tool-like portion of the project was the missions, it did not work out well outsourced to an independent program- because the scripting API was still mer. This may work and is more likely being developed internally when we to succeed the closer this task is to had to get started making scripts (a being modular and having few interde- dependency). For internal teams this is pendencies with the game’s developnot that big an inconvenience and hapment. This works especially well when pens on most projects; the engine you are not prepared to staff up and development and content creation increase head count to perform this stages are often overlapping (it is, of minor amount of programming. course, much better to complete your Much more controversial is the engine before content creation starts). outsourcing of the multiplayer portion In the case of missions, we had to have of a game project. The several exammore communication with the external 186 Chapter 12: Outsourcing Strategies mission programmers than was efficient, and we had to perform significant maintenance on the scripts later in the development cycle. The ship editor project worked out better because the folks came forward with a functional prototype of what they wanted to do and just wanted an okay to move forward on what was essentially their own independent project. On Outsourcing Art Art would have to be the next area I would be reluctant to outsource from my core development team. The outsourcing of art is probably the oldest and most well understood of the tasks to outsource. In the days when a single programmer was all that was needed to challenge the modest hardware, it was common to find an artist buddy and buy a month or two of art from him. Now most games have their own internal art teams to produce the required art for the game. There are, however, common exceptions. Movies, Cut Scenes, or Full Motion Video development houses such as Blizzard and Square have developed very large and internationally recognized movie making teams. Sideways Comment on Large Movie Teams Again, you should outsource when you are contemplating work that is beyond your core competency or it would be an overall financial burden to staff up for this work. In the case of Blizzard and Square, both organizations have enjoyed so much historical success that they could easily afford to employ in-house movie teams. This allowed them to create movies that the rest of the game industry can only envy. There is a significant drawback to having a killer in-house movie team of such power—it needs something to do. The most commonly outsourced art tasks are movies in a game. These movies are sometimes called cut scenes, in-game cinematics, or full motion video (FMV), depending on the technique used to create the movies and the role they play in the game. The reason movies are most commonly outsourced is that movies are a laborintensive process that generally requires building assets in a format and of a higher quality than the game’s engine and using tools and techniques that are not applied in the production of assets for the game itself. Large How do you outsource a movie? This is discussed in detail in Chapter 32. I will merely outline the process here. To prepare for outsourcing a movie it is best if your team has a competent storyboard artist who can communicate all of the scenes, actions, and assets that will be required in making the movie. If you lack a sketched storyboard, create one with just words. Take your storyboard to a number of movie houses and ask them to respond with a fixed bid to perform the work. Be sure to define clearly what work you want them to perform. For example, if you want them to create a silent movie that you will later take to an audio house, specify that, or they might include audio in the quote. Also explicitly indicate if you will supply any of the models or other assets featured in the storyboard; otherwise they will assume they are to create these models. Chapter 12: Outsourcing Strategies 187 As the movie houses are responding to your bid request, follow up with their supplied references and ask people who have worked with them before if they are satisfied with the work performed. In the end you will need to choose the movie house based on your own business parameters: fast, cheap, or high quality (which two of the three do you want?). Maybe one of the movie houses can do the work for you in a rush as you need, but at a steep price. Perhaps another has a key art director that you know will nail the movie and you are willing to pay her fee. Or perhaps there is a movie house with a substantial hole in their revenue stream and they are willing to offer a deep discount to keep things flowing. In the end, never grind so hard that you only force them to come back and ask for more money or to underperform the work to get by. 3D Models—Modeling Almost all modern AAA games are 3D games: shooters, strategy games, roleplaying games, and adventure games. The hardware is just so capable that it is pretty much uncompetitive not to be a 3D game. Most game development companies will have their own internal staff of 3D modeling artists. However, your project may be particularly 3D model intensive and you prefer to outsource than staff up, or you may simply be late and you need some extra modeling bandwidth to accomplish your project’s goals. Or perhaps your development organization is relatively young and does not yet have 3D modelers in house; in any of these cases outsourcing your models would be a good idea. How do you outsource a model? Models tend to outsource well because it is relatively easy to specify what you are looking for by way of a sketch and some technical details like poly count, and models are modular and largely have no dependencies on any other aspect of the project. Finally, it is fairly painless to inspect a model for completeness. Approach several art houses with concept sketches of your model— spaceship, racecar, or whatever you need modeled—and provide a complete technical description of the format you need your model delivered in. Consult your own art director and graphics lead to determine if your models can have only triangles or if quads are okay. Determine poly count, and in addition to being textured, specify any other assets such as a damage layer, luminosity, or specularity. What file format— 3D Studio Max or other? Write all of this up and include other parameters such as required delivery date and send it out to the art houses you have prescreened based on the portfolios and references they have sent you. Finally, as stated above, you must select your modeling team based on who is the best fit to your business parameters: fast, cheap, or high quality. In Chapter 32 I will go over this in detail and provide a list of modeling houses for you to contact. Animation and Motion Capture What good would having a fleet of static character models be? Not much—that is why we invented character animation. Roughly speaking, characters can either be animated by hand, using what is called key framing, or the motion can be captured from the movements of a 188 Chapter 12: Outsourcing Strategies live human, called motion capture. In practice, almost all motion capture involves manual animation techniques to smooth out the noise in the data capture to achieve final quality motion as well as to create secondary motions such as facial expressions and hand gestures. A key decision to make is whether you are exclusively key framing or are using motion capture. Motion capture will tend to produce more natural looking, realistic movement, usually also at a greater cost than key framing. Key framing, on the other hand, may be better for your game if you are looking for unrealistic movements such as a game featuring cartoon characters or a game about non-human animating characters. I provide a deeper discussion on the pros and cons of outsourcing motion capture in Chapter 33. TE work practical. It takes game programmers, game artists, a designer, and a producer to call yourself a game development team. Without someone representing all four of these key positions, you should not make games. All of these warnings aside, I did successfully outsource the UI art on a gambling game that I ran back in 1997 when our game development house lacked art bandwidth. To address this we created what is fondly referred to as “programmer art” throughout the industry and kept on tweaking that art until we had exactly the functionality we needed. Then I turned that over to a great guy, Bradley W. Schenck, who I am happy to say is now one of my employees. Audio Audio assets, on the other hand, are an excellent and time-honored set of User Interface Art assets to be outsourced. Audio does not How about outsourcing your user inter- take as long as programming and art to complete. Each of the three major face art? I have strong feelings about outsourcing your UI art. In short, don’t types of audio assets—music, sound do it! UI art is one of the most intimate effects, and voice-over work—require considerable talent, experience, a spebits of your game’s art. It is the UI art cialized toolset, and often contacts with that will need to be tweaked many other talented folk such as cello players times all the way through alpha and beta to get it just right and to accommo- that the rest of us do not regularly maintain (or at least I do not). date new features and changes to existing features. There is almost no Music way I can see a contract to outsource Music is almost always outsourced, and this work; it is simply unfair to keep only the largest of studios choose to asking an artist contractor to revise over and over again the UI as the game keep a staff composer on hand. Keeping a composer year round would take an progresses. Also, the changes in UI extraordinarily versatile composer as tend to be small and incremental and well as at least six major concurrent require an inordinate amount of communication between the programmers, projects. Highly talented and skilled composers are readily available, and all designers, and artists to get right. An out-of-house artist would have to make the composers I have met are rather technical people quite interested in far too many visits onsite to make this AM FL Y Team-Fly® Chapter 12: Outsourcing Strategies 189 game work and willing to deliver their best to make the gaming experience the strongest possible. The first step is to contact a few reputable composers and discuss the vision for the game project with them. Usually, people look into music for their game after a lot of work for the game has been completed. When that is true, it is useful to provide a tape of the game to the composer for review. You have to outline to the composer your total budget for music including post (unless you are taking care of postproduction yourself). Detail how many minutes of music you are looking for and how you would like to break down the music in terms of themes. For example, in Star Trek games we often create a Federation theme for when the player is playing as the Federation as well as themes for the other playable empires such as Klingon and Romulan. Themes are also broken into victory, defeat, battle, and suspense music. If you can, supply your candidate composers with some CDs of music that illustrate what you are looking for; this is as effective as providing a storyboard to illustrate a proposed movie. Your candidate composers should then go away for a week or two and give your project some deep thought. They should then come back to you and give you their proposal of how they will approach the project: number of minutes and whether or not they will perform the music electronically or have live players. If they will have live players, they should articulate how many, the instruments, and the proposed venue for the live performance. As for providing a demonstration of the work, it could go two ways: First, the composer could deliver a small snippet in electronic form; second, he might propose that a palette of new sounds be created before any actual composition work is performed. Review the proposals and go with the composer you feel has been most responsive to your game. This is all discussed in detail in Chapter 28. Sound Effects Sound effects are another excellent set of assets to outsource. To effectively outsource this work, you must have a very good idea of the number of sound effects you are looking for and a strong description of each sound. The game developer creates a cue list of all of the sounds, indicating which ones loop and which do not, stereo or mono, bitdepth, and sample frequency. Ideally, all of the in-game animation that corresponds to the sound effects should be complete (or complete as far as timing) with videotape of each of these animations available for the sound effects engineer to review while making the sounds. If you do not have the animations, then there will be a needless amount of revisions and the sounds will ultimately never quite fit the animation. With your cue list and animation clippings in hand, select three different sounds that should test the range and versatility of the sound engineers. Send out the business parameters, time of delivery, budget, and delivery format as well as the entire cue list, and highlight the three sample test sounds you would like to hear from the sound engineers. If you send it out to half a dozen folks, you will probably end up with one or two who perform two of the sounds well and two or so who perform one of the sounds really well, and the rest just 190 Chapter 12: Outsourcing Strategies miss. Now comes judgment time. After getting it down to three or so choices, I go with professionalism: Which engineer made the best impression to work with? And finally, I get whomever I select to listen to the sounds another engineer might have done better in a particular case to better illustrate what I was looking for. The process of acquiring sound effects is detailed in Chapter 30. the right facilities or the job you need done is so small that it makes sense to do it yourself. (I just have not seen a job too small to have it done right.) Chapter 29 discusses voice-over production in detail. What Else to Outsource Of course there are a few other types of work that could be outsourced. For example, if you are self-publishing something and want to sell direct to Voice-Over consumers, you should look into electronic software distributors and Almost all voice-over work is outsourced to some degree as very few of outsourcing your credit-card-taking activities. us make strong voice actors. Most top Outsourcing web site design makes games these days employ SAG talent, sense only if your team lacks both art and often quite high-profile stars are and web skills; however, a web site used. Voice-over work involves six design is usually well within the grasp roles: the talent, the director, the studio, postproduction, the producer of the of a game development team. Outvoice-over work, and the game design- sourcing the web site hosting makes good sense, and there is a wide variety ers who specify what lines are needed of vendors available; the services are so in the game. standardized that it has become a I recommend using a full-service commodity. voice-over house. The game designer I have seen a few businesses wants to focus on designing the game, advertise themselves as software testnot filling out SAG union paperwork, finding studio time, and organizing the ing labs. While I do believe they will perform very rigorous testing, I do not VO sessions. Your job, in my opinion, is to design believe there is a good market for these the game and come up with a VO script folks to exist in—the ones I know of for all the actors in your game, not han- have failed. I believe you as a developer dle all of the mundane tasks associated will need the facilities to test your own game, and any strong publisher will be with VO production. However, there sure to test your game. could be the odd case where you have Chapter 13: Shipping Your Game 191 Chapter 13 > > > > > > > > > > > > > > > Shipping Your Game Shipping Is a Phase Shipping a game is not a point in time where the game goes instantly from production to a shrink-wrapped product on a shelf at Electronics Boutique; rather it is a process and a phase of the project. Arguably all of the game development process is in support of shipping the game, so shipping starts at the achievement of alpha with the team taking a feature-complete game and trying to make it the most polished game they can before the last final candidate is burned and turned into a glass master. Great games truly become great in the shipping phase, and the masses of mediocre and almost-great games settle into mediocrity in the shipping phase. Sometimes the challenges are just too great to save a mediocre game in the shipping phase: too many bugs, development overran its time budget, the game’s vision has been misplaced. Indeed all of the previous material in this book was set down in the earnest hopes of setting your game up for the greatest degree of success. How Do You Ship a Great Game? There is one way I know to guarantee shipping a great game: Simply play your game (and have others play your game) and keep fixing bugs, correcting flaws, tweaking balance, and performing wholesale changes to your game until it is the most fun, addicting game available. You will see your total dedication to gameplay and quality well rewarded with appreciation from your fans, critical acclaim, and probably strong sales. There is a large downside to this method though: You have no way of anticipating how long it will take to finish your game. Without that knowledge, marketing will not be able to put together a marketing plan, the salespeople will not be able to sell your game into stores with early strength, fans will become frustrated waiting for the game, the game magazine cover that was so precious a year earlier is forgotten, the publisher may choose not to have an open checkbook, and finally, the ultimate sales of the late but great game may not support the additional time and money spent on the project. In short, working on a game incrementally and without a plan until it is well done is a risky method of development, and only the top developers in the industry are such bankable game makers that they can routinely get away with this strategy. 192 Chapter 13: Shipping Your Game The solution to the dilemma of quality versus timeliness can be solved by continuously focusing your whole team’s efforts and all of the resources available to you to achieving the widest bandwidth of play testing, balancing, bug detection and correction, and being as organized as possible in utilizing the time you have to make a great game. While a game is a work of art, the testing and tweaking part of the project can be successfully engineered. I do not claim that you will be able to fix all your bugs, correct all the flaws in your user interface, or actually be brilliant in your game design and balance. I just claim that I have some good suggestions for using your shipping phase time to maximum effect. This chapter acts as an introduction to QA on game projects while Chapter 18 discusses QA methods in depth. Alpha—Feature Complete The industry standards for alpha, beta, final candidate, first playable, and demo vary from publisher to publisher, year to year, and project to project. My definition